[edk2] [PATCH v2] ArmPkg/ArmLib: avoid cache maintenance in PEIMs when executing in place

2016-06-13 Thread Ard Biesheuvel
On some platforms, performing cache maintenance on regions that are backed
by NOR flash result in SErrors. Since cache maintenance is unnecessary in
that case, create a PEIM specific version that only performs said cache
maintenance in its constructor if the module is shadowed in RAM. To avoid
performing the cache maintenance if the MMU code is not used to begin with,
check that explicitly in the constructor.

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

As discussed in the thread dedicated to this subject, the preferred way of
addressing this to split off the MMU manipulation code from ArmLib into a
separate ArmMmuLib, but this affects other packages and platforms. So in the
mean time, let's merge this patch so that D02 can use the upstream ArmLib
unmodified.


 ArmPkg/Library/ArmLib/AArch64/{AArch64LibConstructor.c => 
AArch64BaseLibConstructor.c} |  0
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   
|  2 +-
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf
| 43 +++
 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c 
|  2 +
 ArmPkg/Library/ArmLib/AArch64/AArch64PeiLibConstructor.c   
| 75 
 5 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64LibConstructor.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
similarity index 100%
rename from ArmPkg/Library/ArmLib/AArch64/AArch64LibConstructor.c
rename to ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
index 58684e8492f2..ef9d261b910d 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
@@ -32,7 +32,7 @@ [Sources.AARCH64]
 
   ../Common/AArch64/ArmLibSupport.S
   ../Common/ArmLib.c
-  AArch64LibConstructor.c
+  AArch64BaseLibConstructor.c
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf 
b/ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf
new file mode 100644
index ..c8f0b97750d4
--- /dev/null
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf
@@ -0,0 +1,43 @@
+#/** @file
+#
+# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
+# Portions copyright (c) 2011 - 2014, 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  = AArch64Lib
+  FILE_GUID  = ef20ddf5-b334-47b3-94cf-52ff44c29138
+  MODULE_TYPE= PEIM
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmLib|PEIM PEI_CORE
+  CONSTRUCTOR= AArch64LibConstructor
+
+[Sources.AARCH64]
+  AArch64Lib.c
+  AArch64Mmu.c
+  AArch64ArchTimer.c
+  ArmLibSupportV8.S
+  AArch64Support.S
+  AArch64ArchTimerSupport.S
+
+  ../Common/AArch64/ArmLibSupport.S
+  ../Common/ArmLib.c
+  AArch64PeiLibConstructor.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  MemoryAllocationLib
+  CacheMaintenanceLib
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
index cf9b7222b47b..07864bac28e6 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
@@ -26,6 +26,8 @@
 // We use this index definition to define an invalid block entry
 #define TT_ATTR_INDX_INVALID((UINT32)~0)
 
+INT32 HaveMmuRoutines = 1;
+
 STATIC
 UINT64
 ArmMemoryAttributeToPageAttribute (
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64PeiLibConstructor.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64PeiLibConstructor.c
new file mode 100644
index ..2de9c7c54ed9
--- /dev/null
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64PeiLibConstructor.c
@@ -0,0 +1,75 @@
+#/* @file
+#
+#  Copyright (c) 2016, Linaro 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.
+#
+#*/
+
+#in

Re: [edk2] [PATCH v2] ArmPkg/ArmLib: avoid cache maintenance in PEIMs when executing in place

2016-06-13 Thread Ard Biesheuvel
On 13 June 2016 at 17:45, Mark Rutland <mark.rutl...@arm.com> wrote:
> On Mon, Jun 13, 2016 at 05:26:07PM +0200, Ard Biesheuvel wrote:
>> On some platforms, performing cache maintenance on regions that are backed
>> by NOR flash result in SErrors. Since cache maintenance is unnecessary in
>> that case, create a PEIM specific version that only performs said cache
>> maintenance in its constructor if the module is shadowed in RAM. To avoid
>> performing the cache maintenance if the MMU code is not used to begin with,
>> check that explicitly in the constructor.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>
>> As discussed in the thread dedicated to this subject, the preferred way of
>> addressing this to split off the MMU manipulation code from ArmLib into a
>> separate ArmMmuLib, but this affects other packages and platforms. So in the
>> mean time, let's merge this patch so that D02 can use the upstream ArmLib
>> unmodified.
>
> I'm missing something here (and couldn't figure out which thread covered
> this earlier), and this feels pretty suspect.
>
> Why does cache maintenance to these regions result in SError in the
> first place?
>
> Is the SRAM not accepting some writeback or fetch that occurs as a
> result? How are we protected against natural evictions and/or fetches?
>
> Does the SRAM respond badly to a CMO itself for some reason?
>

It's NOR flash, not SRAM, and it is basically a quirk of the D02
non-DRAM memory bus implementation. I will let Heyi respond with more
details, but this patch is basically a stop gap solution until we
split off the MMU code from ArmLib, which will allow us to deal with
this more elegantly (Currently, the only PEI phase module that
manipulates the page tables with the MMU on, and is likely to split
entries is DxeIpl, which maps the DXE phase stack non-executable. The
only other user is the module that creates the page tables in the
first place, and so does not require the extra caution when splitting
block entries)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2] ArmPkg/ArmLib: avoid cache maintenance in PEIMs when executing in place

2016-06-15 Thread Ard Biesheuvel
On 15 June 2016 at 17:10, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On 13 June 2016 at 16:26, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>> On some platforms, performing cache maintenance on regions that are backed
>> by NOR flash result in SErrors. Since cache maintenance is unnecessary in
>> that case, create a PEIM specific version that only performs said cache
>> maintenance in its constructor if the module is shadowed in RAM. To avoid
>> performing the cache maintenance if the MMU code is not used to begin with,
>> check that explicitly in the constructor.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>

Thanks

Pushed as 469e1e1e4203b5d369fdce790883cb0aa035a744

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


Re: [edk2] [PATCH v3 0/6] Pl011 Driver improvements

2016-06-15 Thread Ard Biesheuvel
On 15 June 2016 at 14:52,   wrote:
> From: Evan Lloyd 
>
> Updates and bug fixes for the PL011 driver in ArmPlatformPkg.
>
> Because of an interface change, ArmVirtPkg/FdtPL011SerialPortLib is also
> updated.
>
> This patchset is a resubmit in response to comments.
> V3 updates are largely cosmetic:
> Patch 1 Additional line length changes in comments.
> Patch 4 Added check on parameter value.
> Patch 5 Updated commit heading.
>
> The code can be examined on GitHub at:
> https://github.com/EvanLloyd/tianocore/commits/pl011_v3
>

I committed these patches (with Laszlo's R-b added to 5/6) as

9f08a052a3e4 ArmPlatformPkg: Tidy PL011 UART driver
aadc64e6a15a ArmPlatformPkg: Update PL011 Serial PCDs to Fixed PCDs
ca0aad698212 ArmPlatformPkg: Remove double write in PL011
f63005282cc5 ArmPlatformPkg: Add support to configure PL011 UART clock
090916d8bc89 ArmVirtPkg/FdtPL011SerialPortLib: Set the PL011 UART clock rate
16146b984db1 ArmPlatformPkg: Fix PL011 Glitches.

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


Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty varstore

2016-06-22 Thread Ard Biesheuvel
On 21 June 2016 at 17:43, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/21/16 12:30, Ard Biesheuvel wrote:
>> Similar to how OVMF implements this, add a FD definition for the varstore
>> firmware volume and the FTW areas. This can be used by host side tooling
>> to manipulate a pristine varstore before presenting it to the guest.
>
> Side question: what host side tooling do you have in mind?
>
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  ArmVirtPkg/ArmVirtQemu.fdf   |  1 +
>>  ArmVirtPkg/ArmVirtQemuKernel.fdf |  1 +
>>  ArmVirtPkg/VarStore.fdf.inc  | 79 
>>  3 files changed, 81 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
>> index 422a2bf1f9a1..ac2f1f17a042 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.fdf
>> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
>> @@ -69,6 +69,7 @@ [FD.QEMU_EFI]
>>  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>>  FV = FVMAIN_COMPACT
>>
>> +!include VarStore.fdf.inc
>>
>>  
>> 
>>  #
>> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf 
>> b/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> index 6db0668a882d..f6dcbc1d5417 100644
>> --- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> +++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> @@ -91,6 +91,7 @@ [FD.QEMU_EFI]
>>  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>>  FV = FVMAIN_COMPACT
>>
>> +!include VarStore.fdf.inc
>>
>>  
>> 
>>  #
>> diff --git a/ArmVirtPkg/VarStore.fdf.inc b/ArmVirtPkg/VarStore.fdf.inc
>> new file mode 100644
>> index ..7d41b6be6adb
>> --- /dev/null
>> +++ b/ArmVirtPkg/VarStore.fdf.inc
>> @@ -0,0 +1,79 @@
>> +## @file
>> +#  FDF include file with Layout Regions that define an empty variable store.
>> +#
>> +#  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
>> +#  Copyright (C) 2014, Red Hat, Inc.
>> +#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
>> +#
>> +#  This program and the accompanying materials are licensed and made 
>> available
>> +#  under the terms and conditions of the BSD License which accompanies this
>> +#  distribution. The full text of the license may be found at
>> +#  http://opensource.org/licenses/bsd-license.php
>> +#
>> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> +#  IMPLIED.
>> +#
>> +##
>> +
>> +[FD.QEMU_VARS]
>
> (1) Unlike under OvmfPkg, this include file doesn't just contain Layout 
> Regions, it contains a full [FD] ("Flash Device Image") section. That's fine, 
> but:
>
> - since you reference OVMF in the commit message, this difference should be 
> mentioned there,
>
> - in the comment at the top of this new file, the "... with Layout Regions" 
> is no longer precise. Please update it.
>
>> +BaseAddress   = 0x0400
>
> (2) This has to be unified with the PcdFlashNvStorageVariableBase PCD setting 
> that is currently seen in the QEMU DSC files, or we'll go mad down the road.
>
> In my opinion, the best way is to DEFINE a macro near the top of this file. 
> Then reference that macro here, in the setting of the BaseAddress token, and 
> also later, in the assignment to PcdFlashNvStorageVariableBase.
>
> For assigning PcdFlashNvStorageVariableBase, there are actually three ways. 
> (They are all documented in the FDF spec.)
>
> * The simplest (but more limited) way is the following syntax:
>
> BaseAddress   = 
> $(VARS_BASE)|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
>
> * The second, more complex (but more versatile) way is to employ a separate 
> SET statement (also in this FDF include file):
>
> BaseAddress   = $(VARS_BASE)
> [...]
> SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase = 
> $(VARS_BASE)
>
> * The third way will actually be the winner, and I'll come to it a bit later.
>
> Finally, remove PcdFlashNvStorageVariableBase from the DSC files whose FDFs 
> pull in this FDF include file.
>
>> +Size  = 0x000c
>> +ErasePolarity = 1
>> +
>> +# This one is tricky, it must be: BlockSize * NumBlocks = Size
>> +BlockSize = 0x0004
>> +NumBlocks = 0x3
>
> (3) Actu

[edk2] [PATCH v2] ArmVirtPkg: add FDF definition for empty varstore

2016-06-22 Thread Ard Biesheuvel
Similar to how OVMF implements this, add a FD definition for the varstore
firmware volume and the FTW areas. The template was taken from the file
OvmfPkg/VarStore.fdf.inc, and subsequently modified to accommodate the
differences in NOR flash layout. This affects the FvLength, Checksum and
BlockMap[0] fields in the FV header, the Size field of the varstore header,
and the Crc and WriteQueueSize fields of the FTW header. The event log
region is not used by ArmVirtQemu, so it has been omitted.

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

This is v2 of my series 'ArmVirtPkg: add empty varstore definition to
ArmVirtQemu' [0], of which patches #1 - #3 have been merged already, so
this v2 consists of a single patch.

Changes:
- move PCD assignments that have a direct correspondence with the varstore
  layout to the varstore [FD] section
- attempted (but failed) to parametrize the boundaries like the OVMF original:
  the [FD] section attributes cannot be set from macros, as it turns out, and
  defining macros only to use them in some of the appropriate places is arguably
  worse
- updated header comment
- updated commit log to describe the delta with the OVMF original

[0] http://thread.gmane.org/gmane.comp.bios.edk2.devel/13501

 ArmVirtPkg/ArmVirtQemu.dsc   | 10 ---
 ArmVirtPkg/ArmVirtQemu.fdf   |  1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 10 ---
 ArmVirtPkg/ArmVirtQemuKernel.fdf |  1 +
 ArmVirtPkg/VarStore.fdf.inc  | 82 
 5 files changed, 84 insertions(+), 20 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 10925c2bb414..8a5306bde0d0 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -147,16 +147,6 @@ [PcdsFixedAtBuild.common]
   #
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
 
-  #
-  # NV Storage PCDs. Use base of 0x0400 for NOR1
-  #
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
-
   # System Memory Base -- fixed at 0x4000_
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x4000
 
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 422a2bf1f9a1..ac2f1f17a042 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -69,6 +69,7 @@ [FD.QEMU_EFI]
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
+!include VarStore.fdf.inc
 
 

 #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 0b4383214209..52f1612179ba 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -136,16 +136,6 @@ [PcdsFixedAtBuild.common]
   #
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
 
-  #
-  # NV Storage PCDs. Use base of 0x0400 for NOR1
-  #
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
-
 [PcdsPatchableInModule.common]
   #
   # This will be overridden in the code
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf b/ArmVirtPkg/ArmVirtQemuKernel.fdf
index 6db0668a882d..f6dcbc1d5417 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
+++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
@@ -91,6 +91,7 @@ [FD.QEMU_EFI]
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
+!include VarStore.fdf.inc
 
 

 #
diff --git a/ArmVirtPkg/VarStore.fdf.inc b/ArmVirtPkg/VarStore.fdf.inc
new file mode 100644
index ..46852ff149cf
--- /dev/null
+++ b/ArmVirtPkg/VarStore.fdf.inc
@@ -0,0 +1,82 @@
+## @file
+#  FDF include file with FD definition that defines an empty variable store.
+#
+#  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+#  Copyright (C) 2014, Red Hat, Inc.
+#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTR

[edk2] [PATCH] ArmPkg/ArmGicV3Dxe: configure all interrupts as non-secure Group-1

2016-06-22 Thread Ard Biesheuvel
Reassign all interrupts to non-secure Group-1 if the GIC has its DS
(Disable Security) bit set. In this case, it is safe to assume that we
own the GIC, and that no other firmware has performed any configuration
yet, which means it is up to us to reconfigure the interrupts so they
can be taken by the non-secure firmware.

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

This is the EDK2 counterpart of Peter's patch against the Linux kernel

7c9b973061b0 ("irqchip/gic-v3: Configure all interrupts as non-secure Group-1")

which tweaks the GICv3 driver so that it works with the GICv3 emulation in
QEMU, which only emulates a single GIC security state when running without
the security extensions.

 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 16 
 ArmPkg/Include/Library/ArmGicLib.h|  5 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
index 50fa56262eaf..106c669fcb87 100644
--- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
@@ -297,6 +297,22 @@ GicV3DxeInitialize (
 MpId = ArmReadMpidr ();
 CpuTarget = MpId & (ARM_CORE_AFF0 | ARM_CORE_AFF1 | ARM_CORE_AFF2 | 
ARM_CORE_AFF3);
 
+if ((MmioRead32 (mGicDistributorBase + ARM_GIC_ICDDCR) & 
ARM_GIC_ICDDCR_DS) != 0) {
+  //
+  // If the Disable Security (DS) control bit is set, we are dealing with a
+  // GIC that has only one security state. In this case, let's assume we 
are
+  // executing in non-secure state (which is appropriate for DXE modules)
+  // and that no other firmware has performed any configuration on the GIC.
+  // This means we need to reconfigure all interrupts to non-secure Group 1
+  // first.
+  //
+  MmioWrite32 (mGicRedistributorsBase + ARM_GICR_CTLR_FRAME_SIZE + 
ARM_GIC_ICDISR, 0x);
+
+  for (Index = 32; Index < mGicNumInterrupts; Index += 32) {
+MmioWrite32 (mGicDistributorBase + ARM_GIC_ICDISR + Index / 8, 
0x);
+  }
+}
+
 // Route the SPIs to the primary CPU. SPIs start at the INTID 32
 for (Index = 0; Index < (mGicNumInterrupts - 32); Index++) {
   MmioWrite32 (mGicDistributorBase + ARM_GICD_IROUTER + (Index * 8), 
CpuTarget | ARM_GICD_IROUTER_IRM);
diff --git a/ArmPkg/Include/Library/ArmGicLib.h 
b/ArmPkg/Include/Library/ArmGicLib.h
index 10c4a9d72eb2..4364f3ffef46 100644
--- a/ArmPkg/Include/Library/ArmGicLib.h
+++ b/ArmPkg/Include/Library/ArmGicLib.h
@@ -47,8 +47,9 @@
 // GICv3 specific registers
 #define ARM_GICD_IROUTER0x6100 // Interrupt Routing Registers
 
-// the Affinity Routing Enable (ARE) bit in GICD_CTLR
-#define ARM_GIC_ICDDCR_ARE  (1 << 4)
+// GICD_CTLR bits
+#define ARM_GIC_ICDDCR_ARE  (1 << 4) // Affinity Routing Enable (ARE)
+#define ARM_GIC_ICDDCR_DS   (1 << 6) // Disable Security (DS)
 
 //
 // GIC Redistributor
-- 
2.7.4

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


Re: [edk2] [PATCH 0/4] ArmVirtPkg: add empty varstore definition to ArmVirtQemu

2016-06-22 Thread Ard Biesheuvel
On 22 June 2016 at 16:46, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Tue, Jun 21, 2016 at 12:30:30PM +0200, Ard Biesheuvel wrote:
>> This series refactors some of the NOR flash code in ArmPlatformPkg and
>> ArmVirtPkg so that we can add an empty varstore definition to the
>> ArmVirtQemu amd ArmVirtQemuKernel FDFs. The refactoring is necessary to make
>> NorFlashDxe deal with either of the GUIDs gEfiAuthenticatedVariableGuid and
>> gEfiVariableGuid in the varstore FV headers, and is an improvement by itself,
>> since it allows us to get rid of the 'secure boot' flavor of NorFlashDxe.
>
>
>
>> Ard Biesheuvel (4):
>>   ArmPlatformPkg/NorFlashDxe: accept both non-secure and secure varstore
>> GUIDs
>
> For 1/4:
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>
>>   ArmVirtPkg/ArmVirtQemu: switch secure boot build to NorFlashDxe
>>   ArmPlatformPkg/NorFlashAuthenticatedDxe: remove this obsolete module
>
> For 3/4:
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>

Thanks. As suggested by Laszlo, I have merged the first three patches

8753858f8476 ArmPlatformPkg/NorFlashDxe: accept both non-secure and
secure varstore GUIDs
146961937861 ArmVirtPkg/ArmVirtQemu: switch secure boot build to NorFlashDxe
3460c75dfe95 ArmPlatformPkg/NorFlashAuthenticatedDxe: remove this
obsolete module
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 3/4] ArmPlatformPkg/NorFlashAuthenticatedDxe: remove this obsolete module

2016-06-21 Thread Ard Biesheuvel
This module is now identical in functionality to NorFlashDxe, and is no
longer used, so remove it altogether.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf | 77 

 1 file changed, 77 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
deleted file mode 100644
index 0e25b8f6ed6d..
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
+++ /dev/null
@@ -1,77 +0,0 @@
-#/** @file
-#
-#  Component description file for NorFlashAuthenticatedDxe module
-#
-#  Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
-#  Copyright (c) 2015, Linaro Ltd. All rights reserved.
-#  Copyright (c) 2015, Intel Corporation. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#**/
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = NorFlashAuthenticatedDxe
-  FILE_GUID  = 10B86CEA-F2FE-456A-B1C7-4F506CA46005
-  MODULE_TYPE= DXE_RUNTIME_DRIVER
-  VERSION_STRING = 1.0
-  ENTRY_POINT= NorFlashInitialise
-
-[Sources.common]
-  NorFlashDxe.c
-  NorFlashFvbDxe.c
-  NorFlashBlockIoDxe.c
-
-[Packages]
-  MdePkg/MdePkg.dec
-  MdeModulePkg/MdeModulePkg.dec
-  ArmPlatformPkg/ArmPlatformPkg.dec
-  SecurityPkg/SecurityPkg.dec
-
-[LibraryClasses]
-  IoLib
-  BaseLib
-  DebugLib
-  HobLib
-  NorFlashPlatformLib
-  UefiLib
-  UefiDriverEntryPoint
-  UefiBootServicesTableLib
-  UefiRuntimeLib
-  DxeServicesTableLib
-
-[Guids]
-  gEfiSystemNvDataFvGuid
-  gEfiVariableGuid
-  gEfiAuthenticatedVariableGuid
-  gEfiEventVirtualAddressChangeGuid
-
-[Protocols]
-  gEfiBlockIoProtocolGuid
-  gEfiDevicePathProtocolGuid
-  gEfiFirmwareVolumeBlockProtocolGuid
-  gEfiDiskIoProtocolGuid
-
-[Pcd.common]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
-
-  gArmPlatformTokenSpaceGuid.PcdNorFlashCheckBlockLocked
-
-[Depex]
-  #
-  # NorFlashAuthenticatedDxe must be loaded before VariableRuntimeDxe
-  # in case empty flash needs populating with default values
-  #
-  BEFORE gVariableRuntimeDxeFileGuid
-- 
2.7.4

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


[edk2] [PATCH 0/4] ArmVirtPkg: add empty varstore definition to ArmVirtQemu

2016-06-21 Thread Ard Biesheuvel
This series refactors some of the NOR flash code in ArmPlatformPkg and
ArmVirtPkg so that we can add an empty varstore definition to the
ArmVirtQemu amd ArmVirtQemuKernel FDFs. The refactoring is necessary to make
NorFlashDxe deal with either of the GUIDs gEfiAuthenticatedVariableGuid and
gEfiVariableGuid in the varstore FV headers, and is an improvement by itself,
since it allows us to get rid of the 'secure boot' flavor of NorFlashDxe.

Ard Biesheuvel (4):
  ArmPlatformPkg/NorFlashDxe: accept both non-secure and secure varstore
GUIDs
  ArmVirtPkg/ArmVirtQemu: switch secure boot build to NorFlashDxe
  ArmPlatformPkg/NorFlashAuthenticatedDxe: remove this obsolete module
  ArmVirtPkg: add FDF definition for empty varstore

 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf   | 77 
---
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedVariableDep.c | 19 
-
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h  |  2 -
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf|  2 +-
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c   |  5 +-
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashVariableDep.c  | 19 
-
 ArmVirtPkg/ArmVirtQemu.dsc|  4 -
 ArmVirtPkg/ArmVirtQemu.fdf|  5 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc  |  4 -
 ArmVirtPkg/ArmVirtQemuKernel.fdf  |  5 +-
 ArmVirtPkg/VarStore.fdf.inc   | 79 

 11 files changed, 85 insertions(+), 136 deletions(-)
 delete mode 100644 
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
 delete mode 100644 
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedVariableDep.c
 delete mode 100644 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashVariableDep.c
 create mode 100644 ArmVirtPkg/VarStore.fdf.inc

-- 
2.7.4

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


[edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty varstore

2016-06-21 Thread Ard Biesheuvel
Similar to how OVMF implements this, add a FD definition for the varstore
firmware volume and the FTW areas. This can be used by host side tooling
to manipulate a pristine varstore before presenting it to the guest.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/ArmVirtQemu.fdf   |  1 +
 ArmVirtPkg/ArmVirtQemuKernel.fdf |  1 +
 ArmVirtPkg/VarStore.fdf.inc  | 79 
 3 files changed, 81 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 422a2bf1f9a1..ac2f1f17a042 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -69,6 +69,7 @@ [FD.QEMU_EFI]
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
+!include VarStore.fdf.inc
 
 

 #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf b/ArmVirtPkg/ArmVirtQemuKernel.fdf
index 6db0668a882d..f6dcbc1d5417 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
+++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
@@ -91,6 +91,7 @@ [FD.QEMU_EFI]
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
+!include VarStore.fdf.inc
 
 

 #
diff --git a/ArmVirtPkg/VarStore.fdf.inc b/ArmVirtPkg/VarStore.fdf.inc
new file mode 100644
index ..7d41b6be6adb
--- /dev/null
+++ b/ArmVirtPkg/VarStore.fdf.inc
@@ -0,0 +1,79 @@
+## @file
+#  FDF include file with Layout Regions that define an empty variable store.
+#
+#  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+#  Copyright (C) 2014, Red Hat, Inc.
+#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution. The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
+#
+##
+
+[FD.QEMU_VARS]
+BaseAddress   = 0x0400
+Size  = 0x000c
+ErasePolarity = 1
+
+# This one is tricky, it must be: BlockSize * NumBlocks = Size
+BlockSize = 0x0004
+NumBlocks = 0x3
+
+0x|0x0004
+#NV_VARIABLE_STORE
+DATA = {
+  ## This is the EFI_FIRMWARE_VOLUME_HEADER
+  # ZeroVector []
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  # FileSystemGuid: gEfiSystemNvDataFvGuid =
+  #   { 0xFFF12B8D, 0x7696, 0x4C8B,
+  # { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
+  0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
+  0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
+  # FvLength: 0xC
+  0x00, 0x00, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00,
+  # Signature "_FVH"   # Attributes
+  0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
+  # HeaderLength # CheckSum # ExtHeaderOffset #Reserved #Revision
+  0x48, 0x00, 0x28, 0x09, 0x00, 0x00, 0x00, 0x02,
+  # Blockmap[0]: 0x3 Blocks * 0x4 Bytes / Block
+  0x3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00,
+  # Blockmap[1]: End
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  ## This is the VARIABLE_STORE_HEADER
+  # It is compatible with SECURE_BOOT_ENABLE == FALSE as well.
+  # Signature: gEfiAuthenticatedVariableGuid =
+  #   { 0xaaf32c78, 0x947b, 0x439a,
+  # { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
+  0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
+  0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
+  # Size: 0x4 
(gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
+  # 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3ffb8
+  # This can speed up the Variable Dispatch a bit.
+  0xB8, 0xFF, 0x03, 0x00,
+  # FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
+  0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+0x0004|0x0004
+#NV_FTW_WORKING
+DATA = {
+  # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = 
gEdkiiWorkingBlockSignatureGuid =
+  #  { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 
0x95 }}
+  0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+  0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95,
+  # Crc:UINT32#WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+  0x5b, 0xe7, 0xc6, 0x86, 0xFE, 0xFF, 0xFF, 0xFF,
+  # WriteQueueSize: UINT64
+  0xE0, 0xFF, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+0x0008|0x0004
+#NV_FTW_SPARE
-- 
2.7.4

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


[edk2] [PATCH 2/4] ArmVirtPkg/ArmVirtQemu: switch secure boot build to NorFlashDxe

2016-06-21 Thread Ard Biesheuvel
There is no longer a reason to use a different implementation of
NorFlashDxe for secure boot builds now that the varstore FV header can
carry either gEfiVariableGuid or gEfiAuthenticatedVariableGuid, and the
dependent code has been updated to deal with that. So move the secure
boot capable builds to the common NorFlashDxe.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 4 
 ArmVirtPkg/ArmVirtQemu.fdf   | 4 
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 4 
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 4 
 4 files changed, 16 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index d07593b45e27..4958b577ea06 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -314,11 +314,7 @@ [Components.common]
 
   
NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
   }
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
-!else
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-!endif
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 012f65e99038..422a2bf1f9a1 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -136,11 +136,7 @@ [FV.FvMain]
 
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
-!else
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-!endif
   INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 65e6c875204f..f652689054dc 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -292,11 +292,7 @@ [Components.common]
 
   
NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
   }
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
-!else
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-!endif
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf b/ArmVirtPkg/ArmVirtQemuKernel.fdf
index 1a2652fd5068..6db0668a882d 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
+++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
@@ -157,11 +157,7 @@ [FV.FvMain]
 
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
-!else
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-!endif
   INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
-- 
2.7.4

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


[edk2] [PATCH 1/4] ArmPlatformPkg/NorFlashDxe: accept both non-secure and secure varstore GUIDs

2016-06-21 Thread Ard Biesheuvel
Now that the generic Variable Runtime DXE code no longer distinguishes
between gEfiVariableGuid and gEfiAuthenticatedVariableGuid in the varstore
FV header, we can relax the check in the NOR flash driver to accept either
GUID regardless of whether we are running a secure boot capable build or not.

This also means we can always use gEfiAuthenticatedVariableGuid when we
encounter an empty NOR flash that needs to be initialized before use. So
remove the mNorFlashVariableGuid global from the shared code and from both
versions of NorFlashDxe.inf. This essentially collapses the two drivers into
a single one, which means we can remove NorFlashAuthenticatedDxe entirely
in a subsequent patch.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf   |  2 +-
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedVariableDep.c | 19 
---
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h  |  2 --
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf|  2 +-
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c   |  5 
+++--
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashVariableDep.c  | 19 
---
 6 files changed, 5 insertions(+), 44 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
index 6c5e6aef0ddf..0e25b8f6ed6d 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
@@ -28,7 +28,6 @@ [Sources.common]
   NorFlashDxe.c
   NorFlashFvbDxe.c
   NorFlashBlockIoDxe.c
-  NorFlashAuthenticatedVariableDep.c
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -50,6 +49,7 @@ [LibraryClasses]
 
 [Guids]
   gEfiSystemNvDataFvGuid
+  gEfiVariableGuid
   gEfiAuthenticatedVariableGuid
   gEfiEventVirtualAddressChangeGuid
 
diff --git 
a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedVariableDep.c 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedVariableDep.c
deleted file mode 100644
index 2ea8ead85d9b..
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedVariableDep.c
+++ /dev/null
@@ -1,19 +0,0 @@
-/** @file  NorFlashAuthenticatedVariableDep.c
-
-  Copyright (c) 2015, Linaro Ltd. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include 
-
-#include 
-
-CONST EFI_GUID* CONST mNorFlashVariableGuid = 
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
index d0b5c5b12f9e..c24680098f62 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
@@ -152,8 +152,6 @@ struct _NOR_FLASH_INSTANCE {
   NOR_FLASH_DEVICE_PATH   DevicePath;
 };
 
-extern CONST EFI_GUID* CONST  mNorFlashVariableGuid;
-
 EFI_STATUS
 NorFlashReadCfiData (
   IN  UINTN   DeviceBaseAddress,
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
index 563d7573e7a2..812dafd065b2 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
@@ -26,7 +26,6 @@ [Sources.common]
   NorFlashDxe.c
   NorFlashFvbDxe.c
   NorFlashBlockIoDxe.c
-  NorFlashVariableDep.c
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -48,6 +47,7 @@ [LibraryClasses]
 [Guids]
   gEfiSystemNvDataFvGuid
   gEfiVariableGuid
+  gEfiAuthenticatedVariableGuid
   gEfiEventVirtualAddressChangeGuid
 
 [Protocols]
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
index e0edc62c95eb..42be5c2a2dad 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
@@ -111,7 +111,7 @@ InitializeFvAndVariableStoreHeaders (
   // VARIABLE_STORE_HEADER
   //
   VariableStoreHeader = (VARIABLE_STORE_HEADER*)((UINTN)Headers + 
FirmwareVolumeHeader->HeaderLength);
-  CopyGuid (>Signature, mNorFlashVariableGuid);
+  CopyGuid (>Signature, );
   VariableStoreHeader->Size = PcdGet32(PcdFlashNvStorageVariableSize) - 
FirmwareVolumeHeader->HeaderLength;
   VariableStoreHeader->Format= VARIABLE_STORE_FORMATTED;
   VariableStoreHeader->State = VARIABLE_STORE_HEALTHY;
@@ -181,7 +181,8 @@ ValidateFvHeader (
   VariableStoreHea

[edk2] [PATCH 1/4] ArmPkg: introduce ArmMmuLib library class

2016-06-16 Thread Ard Biesheuvel
Introduce the library class ArmMmuLib, which encapsulates the functionality
to set up and modify page table entries.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPkg/ArmPkg.dec  |  1 +
 ArmPkg/Include/Library/ArmMmuLib.h | 65 
 2 files changed, 66 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 75c238aa1e3d..c189117c674d 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -34,6 +34,7 @@ [Includes.common]
 
 [LibraryClasses.common]
   ArmLib|Include/Library/ArmLib.h
+  ArmMmuLib|Include/Library/ArmMmuLib.h
   SemihostLib|Include/Library/Semihosting.h
   UncachedMemoryAllocationLib|Include/Library/UncachedMemoryAllocationLib.h
   DefaultExceptionHandlerLib|Include/Library/DefaultExceptionHandlerLib.h
diff --git a/ArmPkg/Include/Library/ArmMmuLib.h 
b/ArmPkg/Include/Library/ArmMmuLib.h
new file mode 100644
index ..c1d43872d548
--- /dev/null
+++ b/ArmPkg/Include/Library/ArmMmuLib.h
@@ -0,0 +1,65 @@
+/** @file
+
+  Copyright (c) 2015 - 2016, Linaro Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __ARM_MMU_LIB__
+#define __ARM_MMU_LIB__
+
+#include 
+
+#include 
+
+EFI_STATUS
+EFIAPI
+ArmConfigureMmu (
+  IN  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable,
+  OUT VOID  **TranslationTableBase OPTIONAL,
+  OUT UINTN *TranslationTableSize  OPTIONAL
+  );
+
+EFI_STATUS
+EFIAPI
+ArmSetMemoryRegionNoExec (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+EFI_STATUS
+EFIAPI
+ArmClearMemoryRegionNoExec (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+EFI_STATUS
+EFIAPI
+ArmSetMemoryRegionReadOnly (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+EFI_STATUS
+EFIAPI
+ArmClearMemoryRegionReadOnly (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+VOID
+EFIAPI
+ArmReplaceLiveTranslationEntry (
+  IN  UINT64  *Entry,
+  IN  UINT64  Value
+  );
+
+#endif
-- 
1.9.1

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


[edk2] [PATCH 3/4] ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib

2016-06-16 Thread Ard Biesheuvel
Switch all users of ArmLib that depend on the MMU routines to the new,
separate ArmMmuLib. This needs to occur in one go, since the MMU
routines are removed from ArmLib build at the same time, to prevent
conflicting symbols.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |   1 +
 ArmPkg/Include/Library/ArmLib.h|  38 -
 ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c  |  36 -
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   3 -
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   1 -
 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 751 

 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S  |   6 -
 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|   6 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  12 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf   |   1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf  |   1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 418 
---
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |   5 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |   4 -
 ArmVirtPkg/ArmVirtQemu.dsc |   2 +
 ArmVirtPkg/ArmVirtXen.dsc  |   2 +
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   |   1 +
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf |   1 +
 MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c |   1 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   1 +
 20 files changed, 9 insertions(+), 1282 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
index 21cdf319d45b..b31c994f43e2 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
@@ -45,6 +45,7 @@ [Packages]
 
 [LibraryClasses]
   ArmLib
+  ArmMmuLib
   BaseMemoryLib
   CacheMaintenanceLib
   CpuLib
diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
index 4608b0cc..40d97e09b566 100644
--- a/ArmPkg/Include/Library/ArmLib.h
+++ b/ArmPkg/Include/Library/ArmLib.h
@@ -371,14 +371,6 @@ ArmGetTTBR0BaseAddress (
   VOID
   );
 
-RETURN_STATUS
-EFIAPI
-ArmConfigureMmu (
-  IN  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable,
-  OUT VOID **TranslationTableBase OPTIONAL,
-  OUT UINTN *TranslationTableSize  OPTIONAL
-  );
-
 BOOLEAN
 EFIAPI
 ArmMmuEnabled (
@@ -595,34 +587,4 @@ ArmUnsetCpuActlrBit (
   IN  UINTNBits
   );
 
-RETURN_STATUS
-ArmSetMemoryRegionNoExec (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-RETURN_STATUS
-ArmClearMemoryRegionNoExec (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-RETURN_STATUS
-ArmSetMemoryRegionReadOnly (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-RETURN_STATUS
-ArmClearMemoryRegionReadOnly (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-VOID
-ArmReplaceLiveTranslationEntry (
-  IN  UINT64  *Entry,
-  IN  UINT64  Value
-  );
-
 #endif // __ARM_LIB__
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
deleted file mode 100644
index d2d0d3c15ee3..
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
+++ /dev/null
@@ -1,36 +0,0 @@
-#/* @file
-#
-#  Copyright (c) 2016, Linaro 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 
-
-#include 
-#include 
-
-RETURN_STATUS
-EFIAPI
-AArch64LibConstructor (
-  VOID
-  )
-{
-  extern UINT32 ArmReplaceLiveTranslationEntrySize;
-
-  //
-  // The ArmReplaceLiveTranslationEntry () helper function may be invoked
-  // with the MMU off so we have to ensure that it gets cleaned to the PoC
-  //
-  WriteBackDataCacheRange (ArmReplaceLiveTranslationEntry,
-ArmReplaceLiveTranslationEntrySize);
-
-  return RETURN_SUCCESS;
-}
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf 
b/ArmPkg/Library/ArmLib/AArch64/AArc

[edk2] [PATCH 0/4] ArmPkg: refactor MMU handling routines into separate ArmMmuLib

2016-06-16 Thread Ard Biesheuvel
The MMU routines are only used by a small subset of the users of ArmLib.
In order to prevent all those users to have to run the library constructor
to clean some MMU handling routines to the PoC, split off all MMU handling
into a separate ArmMmuLib.

Ard Biesheuvel (4):
  ArmPkg: introduce ArmMmuLib library class
  ArmPkg: introduce base ArmMmuLib implementation
  ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib
  ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib

 ArmPkg/ArmPkg.dec  
   |  1 +
 ArmPkg/Drivers/CpuDxe/CpuDxe.inf   
   |  1 +
 ArmPkg/Include/Library/ArmLib.h
   | 38 --
 ArmPkg/Include/Library/ArmMmuLib.h 
   | 65 +
 ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c  
   | 36 --
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   
   |  3 -
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  
   |  1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S  
   |  6 --
 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm
   |  6 --
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h 
   | 12 
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf   
   |  1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf  
   |  1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S 
   |  5 --
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   
   |  4 --
 ArmPkg/Library/{ArmLib/AArch64/AArch64Mmu.c => 
ArmMmuLib/AArch64/ArmMmuLibCore.c} | 25 +--
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S   
   | 76 
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c 
   | 60 
 ArmPkg/Library/{ArmLib/ArmV7/ArmV7Mmu.c => ArmMmuLib/Arm/ArmMmuLibCore.c}  
   | 38 +-
 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S  
   | 35 +
 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm
   | 32 +
 ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf 
   | 43 +++
 ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf  
   | 36 ++
 ArmVirtPkg/ArmVirtQemu.dsc 
   |  2 +
 ArmVirtPkg/ArmVirtXen.dsc  
   |  2 +
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   
   |  1 +
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf 
   |  1 +
 MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c 
   |  1 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
   |  1 +
 28 files changed, 414 insertions(+), 119 deletions(-)
 create mode 100644 ArmPkg/Include/Library/ArmMmuLib.h
 delete mode 100644 ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
 rename ArmPkg/Library/{ArmLib/AArch64/AArch64Mmu.c => 
ArmMmuLib/AArch64/ArmMmuLibCore.c} (94%)
 create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
 create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
 rename ArmPkg/Library/{ArmLib/ArmV7/ArmV7Mmu.c => 
ArmMmuLib/Arm/ArmMmuLibCore.c} (93%)
 create mode 100644 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S
 create mode 100644 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm
 create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
 create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf

-- 
1.9.1

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


[edk2] [PATCH 2/4] ArmPkg: introduce base ArmMmuLib implementation

2016-06-16 Thread Ard Biesheuvel
This base library encapsulates the MMU manipulation routines that have been
factored out of ArmLib. The functionality covers initial creation of the 1:1
mapping in the page tables, and remapping regions to change permissions or
cacheability attributes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 768 

 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S |  76 ++
 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c | 452 
 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S|  35 +
 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm  |  32 +
 ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf   |  43 ++
 6 files changed, 1406 insertions(+)

diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c 
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
new file mode 100644
index ..6e05e6085011
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
@@ -0,0 +1,768 @@
+/** @file
+*  File managing the MMU for ARMv8 architecture
+*
+*  Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+*  Copyright (c) 2016, Linaro 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// We use this index definition to define an invalid block entry
+#define TT_ATTR_INDX_INVALID((UINT32)~0)
+
+STATIC
+UINT64
+ArmMemoryAttributeToPageAttribute (
+  IN ARM_MEMORY_REGION_ATTRIBUTES  Attributes
+  )
+{
+  switch (Attributes) {
+  case ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK:
+  case ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK:
+return TT_ATTR_INDX_MEMORY_WRITE_BACK | TT_SH_INNER_SHAREABLE;
+
+  case ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH:
+  case ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_THROUGH:
+return TT_ATTR_INDX_MEMORY_WRITE_THROUGH | TT_SH_INNER_SHAREABLE;
+
+  // Uncached and device mappings are treated as outer shareable by default,
+  case ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED:
+  case ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_UNCACHED_UNBUFFERED:
+return TT_ATTR_INDX_MEMORY_NON_CACHEABLE;
+
+  default:
+ASSERT(0);
+  case ARM_MEMORY_REGION_ATTRIBUTE_DEVICE:
+  case ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_DEVICE:
+if (ArmReadCurrentEL () == AARCH64_EL2)
+  return TT_ATTR_INDX_DEVICE_MEMORY | TT_XN_MASK;
+else
+  return TT_ATTR_INDX_DEVICE_MEMORY | TT_UXN_MASK | TT_PXN_MASK;
+  }
+}
+
+UINT64
+PageAttributeToGcdAttribute (
+  IN UINT64 PageAttributes
+  )
+{
+  UINT64  GcdAttributes;
+
+  switch (PageAttributes & TT_ATTR_INDX_MASK) {
+  case TT_ATTR_INDX_DEVICE_MEMORY:
+GcdAttributes = EFI_MEMORY_UC;
+break;
+  case TT_ATTR_INDX_MEMORY_NON_CACHEABLE:
+GcdAttributes = EFI_MEMORY_WC;
+break;
+  case TT_ATTR_INDX_MEMORY_WRITE_THROUGH:
+GcdAttributes = EFI_MEMORY_WT;
+break;
+  case TT_ATTR_INDX_MEMORY_WRITE_BACK:
+GcdAttributes = EFI_MEMORY_WB;
+break;
+  default:
+DEBUG ((EFI_D_ERROR, "PageAttributeToGcdAttribute: PageAttributes:0x%lX 
not supported.\n", PageAttributes));
+ASSERT (0);
+// The Global Coherency Domain (GCD) value is defined as a bit set.
+// Returning 0 means no attribute has been set.
+GcdAttributes = 0;
+  }
+
+  // Determine protection attributes
+  if (((PageAttributes & TT_AP_MASK) == TT_AP_NO_RO) || ((PageAttributes & 
TT_AP_MASK) == TT_AP_RO_RO)) {
+// Read only cases map to write-protect
+GcdAttributes |= EFI_MEMORY_WP;
+  }
+
+  // Process eXecute Never attribute
+  if ((PageAttributes & (TT_PXN_MASK | TT_UXN_MASK)) != 0 ) {
+GcdAttributes |= EFI_MEMORY_XP;
+  }
+
+  return GcdAttributes;
+}
+
+ARM_MEMORY_REGION_ATTRIBUTES
+GcdAttributeToArmAttribute (
+  IN UINT64 GcdAttributes
+  )
+{
+  switch (GcdAttributes & 0xFF) {
+  case EFI_MEMORY_UC:
+return ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+  case EFI_MEMORY_WC:
+return ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
+  case EFI_MEMORY_WT:
+return ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH;
+  case EFI_MEMORY_WB:
+return ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+  default:
+DEBUG ((EFI_D_ERROR, "GcdAttributeToArmAttribute: 0x%lX attributes is not 
supported.\n", GcdAttributes));
+ASSERT (0);
+return ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+  }
+}
+
+// Describe the T0SZ values for each translation table level
+typedef struc

[edk2] [PATCH 4/4] ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib

2016-06-16 Thread Ard Biesheuvel
This introduces a special version of ArmMmuLib for PEIMs that takes care
only to perform cache maintenance on the live entry replacement routine
if the module is not executing in place. Not only is such cache maintenance
unnecessary in that case, it may be actively harmful on some systems that
fail to tolerate cache maintenance operations on NOR flash regions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c | 60 

 ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf  | 36 
 2 files changed, 96 insertions(+)

diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c 
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
new file mode 100644
index ..91dc1157e79a
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
@@ -0,0 +1,60 @@
+#/* @file
+#
+#  Copyright (c) 2016, Linaro 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 
+
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+ArmMmuPeiLibConstructor (
+  IN   EFI_PEI_FILE_HANDLE   FileHandle,
+  IN CONST EFI_PEI_SERVICES  **PeiServices
+  )
+{
+  extern UINT32 ArmReplaceLiveTranslationEntrySize;
+
+  EFI_FV_FILE_INFO  FileInfo;
+  EFI_STATUSStatus;
+
+  ASSERT (FileHandle != NULL);
+
+  Status = (*PeiServices)->FfsGetFileInfo (FileHandle, );
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Some platforms do not cope very well with cache maintenance being
+  // performed on regions backed by NOR flash. Since the cache maintenance
+  // is unnecessary to begin with in that case, perform it only when not
+  // executing in place.
+  //
+  if ((UINTN)FileInfo.Buffer <= (UINTN)ArmReplaceLiveTranslationEntry &&
+  ((UINTN)FileInfo.Buffer + FileInfo.BufferSize >=
+   (UINTN)ArmReplaceLiveTranslationEntry + 
ArmReplaceLiveTranslationEntrySize)) {
+DEBUG ((EFI_D_INFO, "ArmMmuLib: skipping cache maintenance on XIP 
PEIM\n"));
+  } else {
+DEBUG ((EFI_D_INFO, "ArmMmuLib: performing cache maintenance on shadowed 
PEIM\n"));
+//
+// The ArmReplaceLiveTranslationEntry () helper function may be invoked
+// with the MMU off so we have to ensure that it gets cleaned to the PoC
+//
+WriteBackDataCacheRange (ArmReplaceLiveTranslationEntry,
+  ArmReplaceLiveTranslationEntrySize);
+  }
+
+  return RETURN_SUCCESS;
+}
diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf 
b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
new file mode 100644
index ..14ebf8de673d
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
@@ -0,0 +1,36 @@
+#/** @file
+#
+#  Copyright (c) 2016 Linaro Ltd. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = ArmMmuPeiLib
+  FILE_GUID  = b50d8d53-1ad1-44ea-9e69-8c89d4a6d08b
+  MODULE_TYPE= PEIM
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmMmuLib|PEIM
+  CONSTRUCTOR= ArmMmuPeiLibConstructor
+
+[Sources.AARCH64]
+  AArch64/ArmMmuLibCore.c
+  AArch64/ArmMmuPeiLibConstructor.c
+  AArch64/ArmMmuLibReplaceEntry.S
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  CacheMaintenanceLib
+  MemoryAllocationLib
-- 
1.9.1

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


Re: [edk2] [PATCH 0/4] ArmPkg: refactor MMU handling routines into separate ArmMmuLib

2016-06-16 Thread Ard Biesheuvel
On 16 June 2016 at 12:29, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> The MMU routines are only used by a small subset of the users of ArmLib.
> In order to prevent all those users to have to run the library constructor
> to clean some MMU handling routines to the PoC, split off all MMU handling
> into a separate ArmMmuLib.
>
> Ard Biesheuvel (4):
>   ArmPkg: introduce ArmMmuLib library class
>   ArmPkg: introduce base ArmMmuLib implementation
>   ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib
>   ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib
>

Branch can be found here:
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/arm-mmu-lib
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 3/4] ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib

2016-06-17 Thread Ard Biesheuvel
On 17 June 2016 at 18:30, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/16/16 12:29, Ard Biesheuvel wrote:
>> Switch all users of ArmLib that depend on the MMU routines to the new,
>> separate ArmMmuLib. This needs to occur in one go, since the MMU
>> routines are removed from ArmLib build at the same time, to prevent
>> conflicting symbols.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |   
>> 1 +
>>  ArmPkg/Include/Library/ArmLib.h|  
>> 38 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c  |  
>> 36 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   
>> 3 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   
>> 1 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 
>> 751 
>>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S  |   
>> 6 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|   
>> 6 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  
>> 12 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf   |   
>> 1 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf  |   
>> 1 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 
>> 418 ---
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |   
>> 5 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |   
>> 4 -
>>  ArmVirtPkg/ArmVirtQemu.dsc |   
>> 2 +
>>  ArmVirtPkg/ArmVirtXen.dsc  |   
>> 2 +
>>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   |   
>> 1 +
>>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf |   
>> 1 +
>>  MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c |   
>> 1 +
>>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   
>> 1 +
>>  20 files changed, 9 insertions(+), 1282 deletions(-)
>
> [snip]
>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index 32a5aa977401..3decb11712ff 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -47,6 +47,8 @@ [LibraryClasses.ARM]
>>ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>>
>>  [LibraryClasses.common]
>> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>> +
>># Virtio Support
>>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>
>> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
>> index 594ca6491b7a..ba7ec10db224 100644
>> --- a/ArmVirtPkg/ArmVirtXen.dsc
>> +++ b/ArmVirtPkg/ArmVirtXen.dsc
>> @@ -45,6 +45,8 @@ [LibraryClasses.ARM]
>>ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>>
>>  [LibraryClasses.common]
>> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>> +
>># Virtio Support
>>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>
>> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>> diff --git 
>> a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c 
>> b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
>> index f6c69152848e..251e5314e61d 100644
>> --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
>> +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
>> @@ -15,6 +15,7 @@
>>
>>  #include 
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git 
>> a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf 
>> b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
>> index 9fba16f90f1f..028d6fb5ac28 100644
>> --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
>> +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
>> @@ -34,6 +34,7 @@ [LibraryClasses]
>>DebugLib
>>HobLib
>>ArmLib
>> +  ArmMmuLib
>>ArmPlatformLib
>>CacheMaintenanceLib
>>
>
> Shouldn't you add the library resolution to "ArmVirtQemuKernel.dsc" too?
> That DSC too resolves ArmLib.
>

You're quite right. Thanks for spotting that. I will add it before committing

> Acked-by: Laszlo Ersek <ler...@redhat.com>
>

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


Re: [edk2] [PATCH 4/4] ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib

2016-06-21 Thread Ard Biesheuvel
On 17 June 2016 at 12:32, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Thu, Jun 16, 2016 at 12:29:30PM +0200, Ard Biesheuvel wrote:
>> This introduces a special version of ArmMmuLib for PEIMs that takes care
>> only to perform cache maintenance on the live entry replacement routine
>> if the module is not executing in place. Not only is such cache maintenance
>> unnecessary in that case, it may be actively harmful on some systems that
>> fail to tolerate cache maintenance operations on NOR flash regions.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c | 60 
>> 
>>  ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf  | 36 
>>  2 files changed, 96 insertions(+)
>>
>> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c 
>> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
>> new file mode 100644
>> index ..91dc1157e79a
>> --- /dev/null
>> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
>> @@ -0,0 +1,60 @@
>> +#/* @file
>> +#
>> +#  Copyright (c) 2016, Linaro 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 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +EFI_STATUS
>> +EFIAPI
>> +ArmMmuPeiLibConstructor (
>> +  IN   EFI_PEI_FILE_HANDLE   FileHandle,
>> +  IN CONST EFI_PEI_SERVICES  **PeiServices
>> +  )
>> +{
>> +  extern UINT32 ArmReplaceLiveTranslationEntrySize;
>> +
>> +  EFI_FV_FILE_INFO  FileInfo;
>> +  EFI_STATUSStatus;
>> +
>> +  ASSERT (FileHandle != NULL);
>> +
>> +  Status = (*PeiServices)->FfsGetFileInfo (FileHandle, );
>> +  ASSERT_EFI_ERROR (Status);
>> +
>> +  //
>> +  // Some platforms do not cope very well with cache maintenance being
>> +  // performed on regions backed by NOR flash. Since the cache maintenance
>> +  // is unnecessary to begin with in that case, perform it only when not
>> +  // executing in place.
>> +  //
>
> I think perhaps the wording of the above is confusing me a little bit;
> the thing that makes it not matter is that it is executing in place,
> not that it is backed by NOR, right? Could the statement be flipped?:
>

Actually, a bit of both. But even when we are executing PEI from DRAM,
we should be able to assume that it is clean to the PoC since it is
entered with the MMU off. So that is why the heuristic is based on XIP
rather than whether it is backed by NOR, since the latter is
impossible to detect.

> "Perform it only when not executing in place, since otherwise the
> cache maintenance is unnecessary."
>
> Someone who is less fond of multiple negations in a singe sentence
> than me may prefer to reword it further...
>

How about

"""
Since the firmware image can be assumed to be clean to the PoC when
running XIP, even when PEI is executing from DRAM, we only need to
perform the cache maintenance when not executing in place.
"""
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty varstore

2016-06-21 Thread Ard Biesheuvel
On 21 June 2016 at 17:43, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/21/16 12:30, Ard Biesheuvel wrote:
>> Similar to how OVMF implements this, add a FD definition for the varstore
>> firmware volume and the FTW areas. This can be used by host side tooling
>> to manipulate a pristine varstore before presenting it to the guest.
>
> Side question: what host side tooling do you have in mind?
>

I am not sure, to be honest. Leif mentioned to me that Ubuntu cooked
up some code to create an initial varstore image, and sets variables
in it, but I don't know any of the details, In any case, it may not be
relevent to mention this so I can remove it.

>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  ArmVirtPkg/ArmVirtQemu.fdf   |  1 +
>>  ArmVirtPkg/ArmVirtQemuKernel.fdf |  1 +
>>  ArmVirtPkg/VarStore.fdf.inc  | 79 
>>  3 files changed, 81 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
>> index 422a2bf1f9a1..ac2f1f17a042 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.fdf
>> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
>> @@ -69,6 +69,7 @@ [FD.QEMU_EFI]
>>  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>>  FV = FVMAIN_COMPACT
>>
>> +!include VarStore.fdf.inc
>>
>>  
>> 
>>  #
>> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf 
>> b/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> index 6db0668a882d..f6dcbc1d5417 100644
>> --- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> +++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> @@ -91,6 +91,7 @@ [FD.QEMU_EFI]
>>  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>>  FV = FVMAIN_COMPACT
>>
>> +!include VarStore.fdf.inc
>>
>>  
>> 
>>  #
>> diff --git a/ArmVirtPkg/VarStore.fdf.inc b/ArmVirtPkg/VarStore.fdf.inc
>> new file mode 100644
>> index ..7d41b6be6adb
>> --- /dev/null
>> +++ b/ArmVirtPkg/VarStore.fdf.inc
>> @@ -0,0 +1,79 @@
>> +## @file
>> +#  FDF include file with Layout Regions that define an empty variable store.
>> +#
>> +#  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
>> +#  Copyright (C) 2014, Red Hat, Inc.
>> +#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
>> +#
>> +#  This program and the accompanying materials are licensed and made 
>> available
>> +#  under the terms and conditions of the BSD License which accompanies this
>> +#  distribution. The full text of the license may be found at
>> +#  http://opensource.org/licenses/bsd-license.php
>> +#
>> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> +#  IMPLIED.
>> +#
>> +##
>> +
>> +[FD.QEMU_VARS]
>
> (1) Unlike under OvmfPkg, this include file doesn't just contain Layout 
> Regions, it contains a full [FD] ("Flash Device Image") section. That's fine, 
> but:
>
> - since you reference OVMF in the commit message, this difference should be 
> mentioned there,
>
> - in the comment at the top of this new file, the "... with Layout Regions" 
> is no longer precise. Please update it.
>

OK

>> +BaseAddress   = 0x0400
>
> (2) This has to be unified with the PcdFlashNvStorageVariableBase PCD setting 
> that is currently seen in the QEMU DSC files, or we'll go mad down the road.
>
> In my opinion, the best way is to DEFINE a macro near the top of this file. 
> Then reference that macro here, in the setting of the BaseAddress token, and 
> also later, in the assignment to PcdFlashNvStorageVariableBase.
>
> For assigning PcdFlashNvStorageVariableBase, there are actually three ways. 
> (They are all documented in the FDF spec.)
>
> * The simplest (but more limited) way is the following syntax:
>
> BaseAddress   = 
> $(VARS_BASE)|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
>
> * The second, more complex (but more versatile) way is to employ a separate 
> SET statement (also in this FDF include file):
>
> BaseAddress   = $(VARS_BASE)
> [...]
> SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase = 
> $(VARS_BASE)
>
> * The third way will actually be the winner, and I'll come to it a bit later.
>

Indeed.

> Finally, remove PcdFlashNvStorageVariableBase from the DSC files whose FDFs 
> p

Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty varstore

2016-06-23 Thread Ard Biesheuvel
On 23 June 2016 at 03:43, Gao, Liming <liming@intel.com> wrote:
> Ard:
>   Could you send the updated FDF file that causes build failure? I would like 
> to see what issue here.
>

As it turns out, the defines should go into the associated .DSC file,
in a [Defines] section. The .FDF parser tolerates the DEFINEs, but
ignores them.

So I tried putting the defines in ArmVirt.dsc.inc, which does work to
some extent: these expressions

  DEFINE VARS_SIZE   = ($(VARS_BLOCKS) * $(BLOCK_SIZE))
  DEFINE SPARE_BASE  = (2 * $(BLOCK_SIZE))

are rejected, and need to be open coded.

Since the only macro that is actually used more than once is
BLOCK_SIZE, and considering that moving these defines elsewhere and
open coding some of them defeats the purpose of using macros anyway, I
think it is better to go with my v2 (which Laslzo already indicated he
is ok with)

Thanks,
Ard.


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Wednesday, June 22, 2016 11:43 PM
>> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Leif Lindholm
>> <leif.lindh...@linaro.org>
>> Subject: Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty
>> varstore
>>
>> On 06/22/16 17:30, Ard Biesheuvel wrote:
>> > On 21 June 2016 at 17:43, Laszlo Ersek <ler...@redhat.com> wrote:
>>
>> >> (3) Actually, now I suggest to DEFINE the following macros at the top of
>> the file:
>> >>
>> >> DEFINE VARS_BASE   = 0x0400
>> >> DEFINE VARS_BLOCKS = 3
>> >> DEFINE BLOCK_SIZE  = 0x0004
>> >> DEFINE VARS_SIZE   = ($(VARS_BLOCKS) * $(BLOCK_SIZE))
>> >> DEFINE SPARE_BASE  = (2 * $(BLOCK_SIZE))
>> >>
>> >> (It is possible that the multiplications above will not work in all of the
>> contexts below -- in that case, just open-code the products please, and add
>> some comments.)
>> >>
>> >> Then use these macros, for setting the above FD Tokens, like this:
>> >>
>> >> BaseAddress   = $(VARS_BASE)
>> >
>> > It chokes at this reference already:
>> >
>> > /home/ard/build/edk2/ArmVirtPkg/VarStore.fdf.inc(26): error 3000:
>> > Invalid syntax/format
>> > expected Hex base address near line 26, column 0: BaseAddress
>> > = $(VARS_BASE)
>> >
>> > so this is not going to fly.
>>
>> It's strange. If you check e.g. "OvmfPkgX64.fdf", we definitely use this
>> pattern:
>>
>> [FD.OVMF]
>> BaseAddress   = $(FW_BASE_ADDRESS)
>> --
>> [FD.OVMF_VARS]
>> BaseAddress   = $(FW_BASE_ADDRESS)
>> --
>> [FD.OVMF_CODE]
>> BaseAddress   = $(CODE_BASE_ADDRESS)
>> --
>> [FD.MEMFD]
>> BaseAddress   = $(MEMFD_BASE_ADDRESS)
>>
>> >> Size  = $(VARS_SIZE)
>> >> ErasePolarity = 1
>> >> BlockSize = $(BLOCK_SIZE)
>> >> NumBlocks = $(VARS_BLOCKS)
>> >>
>> >> Furthermore:
>> >>
>> >>> +0x|0x0004
>> >>
>> >> (4) This should use $(BLOCK_SIZE) after the pipe symbol, *plus* assign
>> PcdFlashNvStorageVariableBase and PcdFlashNvStorageVariableSize at once.
>> >>
>> >> The most compact form for that is:
>> >>
>> >> 0x|$(BLOCK_SIZE)
>> >>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|gEfiM
>> deModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>> >>
>> >
>> > I have adopted this for v2, but without the BLOCK_SIZE macro, since I
>> > could not get that to work reliably either.
>>
>> That's again strange! The OvmfPkg*.fdf files use this as well; just run:
>>
>> git grep '|\$' -- OvmfPkg/'*fdf'
>>
>> Something must be wrong with your macro definitions (perhaps due to the
>> way I relayed them to you?) The above methods definitely work. Perhaps
>> we should invite BaseTools people to help us debug this.
>>
>> Thanks
>> Laszlo
>>
>> ___
>> 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] ArmPkg/ArmGicV3Dxe: configure all interrupts as non-secure Group-1

2016-06-23 Thread Ard Biesheuvel
On 23 June 2016 at 15:25, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/22/16 16:32, Ard Biesheuvel wrote:
>> Reassign all interrupts to non-secure Group-1 if the GIC has its DS
>> (Disable Security) bit set. In this case, it is safe to assume that we
>> own the GIC, and that no other firmware has performed any configuration
>> yet, which means it is up to us to reconfigure the interrupts so they
>> can be taken by the non-secure firmware.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>
>> This is the EDK2 counterpart of Peter's patch against the Linux kernel
>>
>> 7c9b973061b0 ("irqchip/gic-v3: Configure all interrupts as non-secure 
>> Group-1")
>>
>> which tweaks the GICv3 driver so that it works with the GICv3 emulation in
>> QEMU, which only emulates a single GIC security state when running without
>> the security extensions.
>>
>>  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 16 
>>  ArmPkg/Include/Library/ArmGicLib.h|  5 +++--
>>  2 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
>> b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
>> index 50fa56262eaf..106c669fcb87 100644
>> --- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
>> +++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
>> @@ -297,6 +297,22 @@ GicV3DxeInitialize (
>>  MpId = ArmReadMpidr ();
>>  CpuTarget = MpId & (ARM_CORE_AFF0 | ARM_CORE_AFF1 | ARM_CORE_AFF2 | 
>> ARM_CORE_AFF3);
>>
>> +if ((MmioRead32 (mGicDistributorBase + ARM_GIC_ICDDCR) & 
>> ARM_GIC_ICDDCR_DS) != 0) {
>> +  //
>> +  // If the Disable Security (DS) control bit is set, we are dealing 
>> with a
>> +  // GIC that has only one security state. In this case, let's assume 
>> we are
>> +  // executing in non-secure state (which is appropriate for DXE 
>> modules)
>> +  // and that no other firmware has performed any configuration on the 
>> GIC.
>> +  // This means we need to reconfigure all interrupts to non-secure 
>> Group 1
>> +  // first.
>> +  //
>> +  MmioWrite32 (mGicRedistributorsBase + ARM_GICR_CTLR_FRAME_SIZE + 
>> ARM_GIC_ICDISR, 0x);
>> +
>> +  for (Index = 32; Index < mGicNumInterrupts; Index += 32) {
>> +MmioWrite32 (mGicDistributorBase + ARM_GIC_ICDISR + Index / 8, 
>> 0x);
>> +  }
>> +}
>> +
>>  // Route the SPIs to the primary CPU. SPIs start at the INTID 32
>>  for (Index = 0; Index < (mGicNumInterrupts - 32); Index++) {
>>MmioWrite32 (mGicDistributorBase + ARM_GICD_IROUTER + (Index * 8), 
>> CpuTarget | ARM_GICD_IROUTER_IRM);
>> diff --git a/ArmPkg/Include/Library/ArmGicLib.h 
>> b/ArmPkg/Include/Library/ArmGicLib.h
>> index 10c4a9d72eb2..4364f3ffef46 100644
>> --- a/ArmPkg/Include/Library/ArmGicLib.h
>> +++ b/ArmPkg/Include/Library/ArmGicLib.h
>> @@ -47,8 +47,9 @@
>>  // GICv3 specific registers
>>  #define ARM_GICD_IROUTER0x6100 // Interrupt Routing Registers
>>
>> -// the Affinity Routing Enable (ARE) bit in GICD_CTLR
>> -#define ARM_GIC_ICDDCR_ARE  (1 << 4)
>> +// GICD_CTLR bits
>> +#define ARM_GIC_ICDDCR_ARE  (1 << 4) // Affinity Routing Enable (ARE)
>> +#define ARM_GIC_ICDDCR_DS   (1 << 6) // Disable Security (DS)
>>
>>  //
>>  // GIC Redistributor
>>
>
> Drew tested this patch; the result is positive:
>
> http://thread.gmane.org/gmane.comp.emulators.qemu/418780/focus=421731
>
> Based on that, I'm synthetizing:
>
> Tested-by: Drew Jones <drjo...@redhat.com>
>

Thanks!

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


Re: [edk2] [PATCH] ArmPkg/ArmGicV3Dxe: configure all interrupts as non-secure Group-1

2016-06-23 Thread Ard Biesheuvel
On 23 June 2016 at 15:51, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Thu, Jun 23, 2016 at 03:26:53PM +0200, Ard Biesheuvel wrote:
>> On 23 June 2016 at 15:25, Laszlo Ersek <ler...@redhat.com> wrote:
>> > On 06/22/16 16:32, Ard Biesheuvel wrote:
>> >> Reassign all interrupts to non-secure Group-1 if the GIC has its DS
>> >> (Disable Security) bit set. In this case, it is safe to assume that we
>> >> own the GIC, and that no other firmware has performed any configuration
>> >> yet, which means it is up to us to reconfigure the interrupts so they
>> >> can be taken by the non-secure firmware.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.0
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> >> ---
>> >>
>> >> This is the EDK2 counterpart of Peter's patch against the Linux kernel
>> >>
>> >> 7c9b973061b0 ("irqchip/gic-v3: Configure all interrupts as non-secure 
>> >> Group-1")
>> >>
>> >> which tweaks the GICv3 driver so that it works with the GICv3 emulation in
>> >> QEMU, which only emulates a single GIC security state when running without
>> >> the security extensions.
>> >>
>> >>  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 16 
>> >>  ArmPkg/Include/Library/ArmGicLib.h|  5 +++--
>> >>  2 files changed, 19 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
>> >> b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
>> >> index 50fa56262eaf..106c669fcb87 100644
>> >> --- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
>> >> +++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
>> >> @@ -297,6 +297,22 @@ GicV3DxeInitialize (
>> >>  MpId = ArmReadMpidr ();
>> >>  CpuTarget = MpId & (ARM_CORE_AFF0 | ARM_CORE_AFF1 | ARM_CORE_AFF2 | 
>> >> ARM_CORE_AFF3);
>> >>
>> >> +if ((MmioRead32 (mGicDistributorBase + ARM_GIC_ICDDCR) & 
>> >> ARM_GIC_ICDDCR_DS) != 0) {
>> >> +  //
>> >> +  // If the Disable Security (DS) control bit is set, we are dealing 
>> >> with a
>> >> +  // GIC that has only one security state. In this case, let's 
>> >> assume we are
>> >> +  // executing in non-secure state (which is appropriate for DXE 
>> >> modules)
>> >> +  // and that no other firmware has performed any configuration on 
>> >> the GIC.
>> >> +  // This means we need to reconfigure all interrupts to non-secure 
>> >> Group 1
>> >> +  // first.
>> >> +  //
>> >> +  MmioWrite32 (mGicRedistributorsBase + ARM_GICR_CTLR_FRAME_SIZE + 
>> >> ARM_GIC_ICDISR, 0x);
>> >> +
>> >> +  for (Index = 32; Index < mGicNumInterrupts; Index += 32) {
>> >> +MmioWrite32 (mGicDistributorBase + ARM_GIC_ICDISR + Index / 8, 
>> >> 0x);
>> >> +  }
>> >> +}
>> >> +
>> >>  // Route the SPIs to the primary CPU. SPIs start at the INTID 32
>> >>  for (Index = 0; Index < (mGicNumInterrupts - 32); Index++) {
>> >>MmioWrite32 (mGicDistributorBase + ARM_GICD_IROUTER + (Index * 8), 
>> >> CpuTarget | ARM_GICD_IROUTER_IRM);
>> >> diff --git a/ArmPkg/Include/Library/ArmGicLib.h 
>> >> b/ArmPkg/Include/Library/ArmGicLib.h
>> >> index 10c4a9d72eb2..4364f3ffef46 100644
>> >> --- a/ArmPkg/Include/Library/ArmGicLib.h
>> >> +++ b/ArmPkg/Include/Library/ArmGicLib.h
>> >> @@ -47,8 +47,9 @@
>> >>  // GICv3 specific registers
>> >>  #define ARM_GICD_IROUTER0x6100 // Interrupt Routing Registers
>> >>
>> >> -// the Affinity Routing Enable (ARE) bit in GICD_CTLR
>> >> -#define ARM_GIC_ICDDCR_ARE  (1 << 4)
>> >> +// GICD_CTLR bits
>> >> +#define ARM_GIC_ICDDCR_ARE  (1 << 4) // Affinity Routing Enable (ARE)
>> >> +#define ARM_GIC_ICDDCR_DS   (1 << 6) // Disable Security (DS)
>> >>
>> >>  //
>> >>  // GIC Redistributor
>> >>
>> >
>> > Drew tested this patch; the result is positive:
>> >
>> > http://thread.gmane.org/gmane.comp.emulators.qemu/418780/focus=421731
>> >
>> > Based on that, I'm synthetizing:
>> >
>> > Tested-by: Drew Jones <drjo...@redhat.com>
>> >
>>
>> Thanks!
>>
>> @Leif: any concerns?
>
> Nope.
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

Thanks all. I committed this as c7fefb690661 (but I forgot to add
Drew's T-b, sorry about that)

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


Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty varstore

2016-06-23 Thread Ard Biesheuvel
On 23 June 2016 at 16:00, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 23 June 2016 at 12:57, Laszlo Ersek <ler...@redhat.com> wrote:
>> On 06/23/16 10:14, Ard Biesheuvel wrote:
>>> On 23 June 2016 at 03:43, Gao, Liming <liming@intel.com> wrote:
>>>> Ard:
>>>>   Could you send the updated FDF file that causes build failure? I would 
>>>> like to see what issue here.
>>>>
>>>
>>> As it turns out, the defines should go into the associated .DSC file,
>>> in a [Defines] section. The .FDF parser tolerates the DEFINEs, but
>>> ignores them.
>>>
>>> So I tried putting the defines in ArmVirt.dsc.inc, which does work to
>>> some extent: these expressions
>>>
>>>   DEFINE VARS_SIZE   = ($(VARS_BLOCKS) * $(BLOCK_SIZE))
>>>   DEFINE SPARE_BASE  = (2 * $(BLOCK_SIZE))
>>>
>>> are rejected, and need to be open coded.
>>>
>>> Since the only macro that is actually used more than once is
>>> BLOCK_SIZE, and considering that moving these defines elsewhere and
>>> open coding some of them defeats the purpose of using macros anyway, I
>>> think it is better to go with my v2 (which Laslzo already indicated he
>>> is ok with)
>>
>> Yes, as I've indicated, I'm fine to proceed with v2.
>>
>
> OK, will do.
>

Thanks all. Committed as bf57a42a0e2c

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


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

2016-06-23 Thread Ard Biesheuvel
On 23 June 2016 at 13:31, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
> ACPI tables through Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao 
> ---
> Changes since v1:
> * move the codes into ArmVirtPkg
> * use FdtClient
> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
>   entry point since it's minor
> * use compatible string to find the DT node instead of node path
>
> If you want to test, the corresponding Xen patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v2
> ---
>  ArmVirtPkg/ArmVirtXen.dsc  |   8 +
>  ArmVirtPkg/ArmVirtXen.fdf  |   8 +
>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 241 
> +
>  .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  |  49 +
>  4 files changed, 306 insertions(+)
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a869986 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,11 @@
>
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..b1e00e5 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,14 @@ READ_LOCK_STATUS   = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c 
> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> new file mode 100644
> index 000..9258be8
> --- /dev/null
> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> @@ -0,0 +1,241 @@
> +/** @file
> +  Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
> +
> +  Copyright (C) 2016, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *XenAcpiRsdpStructurePtr = 
> NULL;
> +

Does this need to be a global? If yes, please add STATIC, and prefix
the name with 'm'. Otherwise, move it into InstallXenArmTables ().

> +/**
> +  Get the address of Xen ACPI Root System Description Pointer (RSDP)
> +  structure.
> +
> +  @param  RsdpStructurePtr   Return pointer to RSDP structure
> +
> +  @return EFI_SUCCESSFind Xen RSDP structure successfully.
> +  @return EFI_NOT_FOUND  Don't find Xen RSDP structure.
> +  @return EFI_ABORTEDFind Xen RSDP structure, but it's not 
> integrated.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +GetXenArmAcpiRsdp (

... and here

> +  OUT   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   **RsdpPtr
> +  )
> +{
> +  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
> +  EFI_STATUS Status;
> +  FDT_CLIENT_PROTOCOL*FdtClient;
> +  CONST UINT64   *Reg;
> +  UINT32 RegElemSize, RegSize;
> +  UINT64 RegBase;
> +  UINT8  Sum;
> +
> +  RsdpStructurePtr = NULL;

Please initialize FdtClient to NULL here.

> +  //
> +  // Get the RSDP structure address from DeviceTree
> +  //
> +  Status = gBS->LocateProtocol (, NULL,

Please add gFdtClientProtocolGuid to the [Depex] section of this module

> +  (VOID **));
> +  ASSERT_EFI_ERROR (Status);
> +
> +  Status = FdtClient->FindCompatibleNodeReg (FdtClient, "xen,guest-acpi",
> +(CONST VOID **), , );
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((EFI_D_WARN, "%a: No 

Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty varstore

2016-06-23 Thread Ard Biesheuvel
On 23 June 2016 at 12:57, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/23/16 10:14, Ard Biesheuvel wrote:
>> On 23 June 2016 at 03:43, Gao, Liming <liming@intel.com> wrote:
>>> Ard:
>>>   Could you send the updated FDF file that causes build failure? I would 
>>> like to see what issue here.
>>>
>>
>> As it turns out, the defines should go into the associated .DSC file,
>> in a [Defines] section. The .FDF parser tolerates the DEFINEs, but
>> ignores them.
>>
>> So I tried putting the defines in ArmVirt.dsc.inc, which does work to
>> some extent: these expressions
>>
>>   DEFINE VARS_SIZE   = ($(VARS_BLOCKS) * $(BLOCK_SIZE))
>>   DEFINE SPARE_BASE  = (2 * $(BLOCK_SIZE))
>>
>> are rejected, and need to be open coded.
>>
>> Since the only macro that is actually used more than once is
>> BLOCK_SIZE, and considering that moving these defines elsewhere and
>> open coding some of them defeats the purpose of using macros anyway, I
>> think it is better to go with my v2 (which Laslzo already indicated he
>> is ok with)
>
> Yes, as I've indicated, I'm fine to proceed with v2.
>

OK, will do.

> Just for curiosity's sake: can you try extracting the DEFINEs in
> question to a separate *FDF* include file? That's how we use them in
> OvmfPkg. Maybe the FDF parser in BaseTools will honor those macro defs
> if their definition and their place of use are separated by an !include
> directive in the FDF file.
>

The trick appears to be that the [Defines] .FDF section needs to
precede any [FD] sections.
That still means a separate .FDF include file just for these macro
defs, so I am not going to bother

-- 
Ard.

>>
>>>> -Original Message-
>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>>> Laszlo Ersek
>>>> Sent: Wednesday, June 22, 2016 11:43 PM
>>>> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Leif Lindholm
>>>> <leif.lindh...@linaro.org>
>>>> Subject: Re: [edk2] [PATCH 4/4] ArmVirtPkg: add FDF definition for empty
>>>> varstore
>>>>
>>>> On 06/22/16 17:30, Ard Biesheuvel wrote:
>>>>> On 21 June 2016 at 17:43, Laszlo Ersek <ler...@redhat.com> wrote:
>>>>
>>>>>> (3) Actually, now I suggest to DEFINE the following macros at the top of
>>>> the file:
>>>>>>
>>>>>> DEFINE VARS_BASE   = 0x0400
>>>>>> DEFINE VARS_BLOCKS = 3
>>>>>> DEFINE BLOCK_SIZE  = 0x0004
>>>>>> DEFINE VARS_SIZE   = ($(VARS_BLOCKS) * $(BLOCK_SIZE))
>>>>>> DEFINE SPARE_BASE  = (2 * $(BLOCK_SIZE))
>>>>>>
>>>>>> (It is possible that the multiplications above will not work in all of 
>>>>>> the
>>>> contexts below -- in that case, just open-code the products please, and add
>>>> some comments.)
>>>>>>
>>>>>> Then use these macros, for setting the above FD Tokens, like this:
>>>>>>
>>>>>> BaseAddress   = $(VARS_BASE)
>>>>>
>>>>> It chokes at this reference already:
>>>>>
>>>>> /home/ard/build/edk2/ArmVirtPkg/VarStore.fdf.inc(26): error 3000:
>>>>> Invalid syntax/format
>>>>> expected Hex base address near line 26, column 0: BaseAddress
>>>>> = $(VARS_BASE)
>>>>>
>>>>> so this is not going to fly.
>>>>
>>>> It's strange. If you check e.g. "OvmfPkgX64.fdf", we definitely use this
>>>> pattern:
>>>>
>>>> [FD.OVMF]
>>>> BaseAddress   = $(FW_BASE_ADDRESS)
>>>> --
>>>> [FD.OVMF_VARS]
>>>> BaseAddress   = $(FW_BASE_ADDRESS)
>>>> --
>>>> [FD.OVMF_CODE]
>>>> BaseAddress   = $(CODE_BASE_ADDRESS)
>>>> --
>>>> [FD.MEMFD]
>>>> BaseAddress   = $(MEMFD_BASE_ADDRESS)
>>>>
>>>>>> Size  = $(VARS_SIZE)
>>>>>> ErasePolarity = 1
>>>>>> BlockSize = $(BLOCK_SIZE)
>>>>>> NumBlocks = $(VARS_BLOCKS)
>>>>>>
>>>>>> Furthermore:
>>>>>>
>>>>>>> +0x|0x0004
>>>>>>
>>>>>> (4) This should use $(BLOCK_SIZE) after the pipe symbol, *plus* assign
>>>> PcdFlashNvStorageVariableBase and PcdFlashNvStorageVariableSize at once.
>>>>>>
>>>>>> The most compact form for that is:
>>>>>>
>>>>>> 0x|$(BLOCK_SIZE)
>>>>>>
>>>> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|gEfiM
>>>> deModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>>>>>>
>>>>>
>>>>> I have adopted this for v2, but without the BLOCK_SIZE macro, since I
>>>>> could not get that to work reliably either.
>>>>
>>>> That's again strange! The OvmfPkg*.fdf files use this as well; just run:
>>>>
>>>> git grep '|\$' -- OvmfPkg/'*fdf'
>>>>
>>>> Something must be wrong with your macro definitions (perhaps due to the
>>>> way I relayed them to you?) The above methods definitely work. Perhaps
>>>> we should invite BaseTools people to help us debug this.
>>>>
>>>> Thanks
>>>> Laszlo
>>>>
>>>> ___
>>>> 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/SerialDxe: fix porting error from EmbeddedPkg

2016-01-15 Thread Ard Biesheuvel
SerialDxe was migrated to MdeModulePkg from EmbeddedPkg, and all
users of the latter were moved to the former. However, the new
version is not quite identical to the original, in ways that break
ARM platforms that use the PL011 driver.

In SerialReset(), the serial port is reset to its default values,
but the defaults used by the new version for ReceiveFifoDepth and
Timeout deviate from the original values. So put them back.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdeModulePkg/Universal/SerialDxe/SerialIo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
index de928d1719e9..9e9db28ce5cc 100644
--- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
+++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
@@ -233,8 +233,8 @@ SerialReset (
   //
   // Set the Serial I/O mode
   //
-  This->Mode->ReceiveFifoDepth  = 1;
-  This->Mode->Timeout   = 0;
+  This->Mode->ReceiveFifoDepth  = 0;
+  This->Mode->Timeout   = 100;
   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
   This->Mode->Parity= (UINT32) PcdGet8 (PcdUartDefaultParity);
-- 
2.5.0

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


Re: [edk2] [PATCH V4 10/13] ArmPlatformPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg

2016-01-15 Thread Ard Biesheuvel
On 15 January 2016 at 18:05, Laszlo Ersek  wrote:
> Hi,
>
> snipping context liberally...
>
>> Whilst simple text input seems to work ok, cursor support does not.
>> And we need cursor support for Intel BDS.
>
> (1) I think this is important. See below.
>
>> When trying to revert your patch on the latest trunk code, the build
>> fails because your patch is doing too many things in one step.  It
>> should have been three (or more) patches, in my opinion.
>
> (2)
>
> (Caveat: what I'm about to say / reference here may not apply fully.)
>
> I just want to say that I followed / partially reviewed Star's patch series 
> (earlier versions of it than v4), and I had the exact same impression (= 
> "this is too big"), about the patch that did more or less the same for 
> ArmVirtPkg.
>
> Surprisingly :), I was wrong. Please see the message of commit
>
> commit ad7f6bc2e1163125cdb26f6b0e6695554028626a
> Author: Star Zeng 
> Date:   Thu Nov 26 08:52:12 2015 +
>
> ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
>
> Also, this sub-thread could be interesting:
>
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/4582/focus=4593
>
>>
>> Instead of reverting, I manually added back PL011SerialPortExtLib and
>> removed the code from PL011SerialPortLib at the same time.  Then, the
>> code did not compile.
>>
>> So I changed my patch to also make PL011SerialPortLib return 0 instead
>> of calling the PL011 functions.  And everything started to work.  I
>> assumed this was because I added back the ExtLib, not because I
>> changed the added code.  I was wrong.
>>
>> I've just pushed a new branch, serialdxe-fix-006, that only changes
>> PL011SerialPortLib.c to "return 0;" for all the new functions - and
>> that works also.
>>
>> So I don't need PL011SerialPortExtLib at all.  I guess it was never
>> called from there?  When you moved the code to PL011SerialPortLib, it
>> started getting called - and the code is causing problems.
>>
>>
>>> Could you check out to *SHA-1: 1b96428d92c01383dc437717db679f57cf70d980*
>>> that just before my SerialDxe series changes, and help to confirm if there
>>> is regression?
>>>
>>
>> I already checked out the commit before yours [1] and it works fine.
>>
>> [1] git checkout 921e987b2b26602dc85eaee856d494b97b6e02b0^
>
> (3) Alright, so SVN r18974 (git 1bccab910700) is the commit that removes the 
> old SerialDxe from EmbeddedPkg. At that stage, all client packages have been 
> converted to the new driver in MdeModulePkg. Therefore, if we want to compare 
> the two *drivers*, we have to check out the parent of this commit (that is, 
> check out SVN r18973 == git 1bccab910700^ == git ad7f6bc2e1), and compare the 
> following files:
>
> - EmbeddedPkg/SerialDxe/SerialIo.c
> - MdeModulePkg/Universal/SerialDxe/SerialIo.c
>
> I don't recommend to diff them -- instead, open them both side by side, and 
> read them in parallel.
>
> This way I noticed the following difference:
>
> (a) In the EmbeddedPkg driver, we have the following *initial* values (not 
> quoting everything, just what I think is relevant):
>
>   EFI_SERIAL_IO_PROTOCOL.Mode->Timeout  = 0
>   EFI_SERIAL_IO_PROTOCOL.Mode->ReceiveFifoDepth = 1
>
> (see gSerialIoTemplate and gSerialIoMode), however the SerialReset() function 
> (implementing the Reset protocol member) sets the following, different values:
>
>   EFI_SERIAL_IO_PROTOCOL.Mode->Timeout  = 100
>   EFI_SERIAL_IO_PROTOCOL.Mode->ReceiveFifoDepth = 0
>
> Inconsistent, right? But that's not the difference I think is relevant:
>
> (b) The MdeModulePkg driver stores the following settings *both* at driver 
> initialization and in SerialReset():
>
>   EFI_SERIAL_IO_PROTOCOL.Mode->Timeout  = 0
>   EFI_SERIAL_IO_PROTOCOL.Mode->ReceiveFifoDepth = 1
>
> (See mSerialIoTemplate and mSerialIoMode.)
>
> That is, the initial state for Mode is identical between the (a) old and (b) 
> new drivers. However, these relevant-looking fields *differ* between old and 
> new driver after a client calls EFI_SERIAL_IO_PROTOCOL.Reset(). Then the old 
> driver sets a ReceiveFifoDepth of zero, while the new driver sets 1. (I'll 
> ignore Timeout for now.)
>
> The UEFI spec says the following about ReceiveFifoDepth:
>
> ReceiveFifoDepthThe number of characters the device will buffer on 
> input.
>
> [...]
>
> The default attributes for all UART-style serial device interfaces
> are: 115,200 baud, a 1 byte receive FIFO, a 1,000,000 microsecond
> timeout per character, no parity, 8 data bits, and 1 stop bit. [...]
>
> Special care must be taken if a significant amount of data is going
> to be read from a serial device. Since UEFI drivers are polled mode
> drivers, characters received on a serial device might be missed. It
> is the responsibility of the software that uses the protocol to
> check for new data often enough to guarantee that no characters will
> be 

Re: [edk2] [PATCH] MdeModulePkg/SerialDxe: fix porting error from EmbeddedPkg

2016-01-15 Thread Ard Biesheuvel
On 15 January 2016 at 17:07, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 15 January 2016 at 15:42, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>> SerialDxe was migrated to MdeModulePkg from EmbeddedPkg, and all
>> users of the latter were moved to the former. However, the new
>> version is not quite identical to the original, in ways that break
>> ARM platforms that use the PL011 driver.
>>
>
> The original patch should never have passed review.
>

My apologies. I did review the patch, but did not notice that the
patch not only moved code around, but also made modifications at the
same time.

@Star: *please*, the next time you want to move code *and* make
changes to it, split it up in separate patches so reviewers don't have
to read through hundreds of lines of code.

Thanks,
Ard.



>
>> In SerialReset(), the serial port is reset to its default values,
>> but the defaults used by the new version for ReceiveFifoDepth and
>> Timeout deviate from the original values. So put them back.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>
>> ---
>>  MdeModulePkg/Universal/SerialDxe/SerialIo.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>> index de928d1719e9..9e9db28ce5cc 100644
>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>> @@ -233,8 +233,8 @@ SerialReset (
>>//
>>// Set the Serial I/O mode
>>//
>> -  This->Mode->ReceiveFifoDepth  = 1;
>> -  This->Mode->Timeout   = 0;
>> +  This->Mode->ReceiveFifoDepth  = 0;
>> +  This->Mode->Timeout   = 100;
>>This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>>This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>This->Mode->Parity= (UINT32) PcdGet8 (PcdUartDefaultParity);
>> --
>> 2.5.0
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2] ARM: Virt: Don't generate RTC ACPI device when using UEFI

2016-01-13 Thread Ard Biesheuvel
On 13 January 2016 at 15:54, Shannon Zhao <shannon.z...@linaro.org> wrote:
> When booting the VM with UEFI, UEFI takes ownership of the RTC hardware.
> While UEFI can use libfdt to disable the RTC device node in the DTB that
> it passes to the OS, it cannot modify AML. Therefore, we won't generate
> the RTC ACPI device at all when using UEFI.
>
> Signed-off-by: Shannon Zhao <shannon.z...@linaro.org>
> ---

Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

> v2: just totally don't generate the RTC ACPI device when using UEFI
> ---
>  hw/arm/virt-acpi-build.c | 19 ---
>  1 file changed, 19 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 0caf5ce..ac568a3 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -94,23 +94,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const 
> MemMapEntry *uart_memmap,
>  aml_append(scope, dev);
>  }
>
> -static void acpi_dsdt_add_rtc(Aml *scope, const MemMapEntry *rtc_memmap,
> -  uint32_t rtc_irq)
> -{
> -Aml *dev = aml_device("RTC0");
> -aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0013")));
> -aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> -
> -Aml *crs = aml_resource_template();
> -aml_append(crs, aml_memory32_fixed(rtc_memmap->base,
> -   rtc_memmap->size, AML_READ_WRITE));
> -aml_append(crs,
> -   aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH,
> - AML_EXCLUSIVE, _irq, 1));
> -aml_append(dev, aml_name_decl("_CRS", crs));
> -aml_append(scope, dev);
> -}
> -
>  static void acpi_dsdt_add_flash(Aml *scope, const MemMapEntry *flash_memmap)
>  {
>  Aml *dev, *crs;
> @@ -575,8 +558,6 @@ build_dsdt(GArray *table_data, GArray *linker, 
> VirtGuestInfo *guest_info)
>  acpi_dsdt_add_cpus(scope, guest_info->smp_cpus);
>  acpi_dsdt_add_uart(scope, [VIRT_UART],
> (irqmap[VIRT_UART] + ARM_SPI_BASE));
> -acpi_dsdt_add_rtc(scope, [VIRT_RTC],
> -  (irqmap[VIRT_RTC] + ARM_SPI_BASE));
>  acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
>  acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
>  (irqmap[VIRT_MMIO] + ARM_SPI_BASE), 
> NUM_VIRTIO_TRANSPORTS);
> --
> 2.1.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/2] ArmPlatformPkg: Remove FVP and Juno

2016-01-18 Thread Ard Biesheuvel
On 18 January 2016 at 15:29, Ryan Harkin  wrote:
> ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].
>
> Currently, Juno and FVP exist both in EDK2's ArmPlatformPkg and in
> OpenPlatformPkg.  And they are starting to diverge, with
> OpenPlatformPkg being the most up-to-date with current developments.
> To prevent this divergence, remove the .dsc and .fdf files from
> ArmPlatformPkg and leave OpenPlatformPkg as the master.
>
> We can't remove ArmJuno.dec yet because ACPI still uses it to set the
> include path to ArmPlatform.h.
>
> [PATCH 1/2] ArmPlatformPkg: remove ArmVExpress-FVP-AArch64
> [PATCH 2/2] ArmPlatformPkg: remove ArmJuno.dsc/fdf
>
>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 291 
> ---
>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 365 
> -
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 317 
> -
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 401 
> --
>
> [1] https://git.linaro.org/uefi/OpenPlatformPkg.git

Shouldn't we sync OpenPlatformPkg with the latest EDK2 versions first?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/2] ArmPlatformPkg: Remove FVP and Juno

2016-01-18 Thread Ard Biesheuvel
On 18 January 2016 at 16:28, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 18 January 2016 at 15:11, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>> On 18 January 2016 at 16:08, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>> On 18 January 2016 at 14:39, Ard Biesheuvel <ard.biesheu...@linaro.org> 
>>> wrote:
>>>> On 18 January 2016 at 15:29, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>>>> ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].
>>>>>
>>>>> Currently, Juno and FVP exist both in EDK2's ArmPlatformPkg and in
>>>>> OpenPlatformPkg.  And they are starting to diverge, with
>>>>> OpenPlatformPkg being the most up-to-date with current developments.
>>>>> To prevent this divergence, remove the .dsc and .fdf files from
>>>>> ArmPlatformPkg and leave OpenPlatformPkg as the master.
>>>>>
>>>>> We can't remove ArmJuno.dec yet because ACPI still uses it to set the
>>>>> include path to ArmPlatform.h.
>>>>>
>>>>> [PATCH 1/2] ArmPlatformPkg: remove ArmVExpress-FVP-AArch64
>>>>> [PATCH 2/2] ArmPlatformPkg: remove ArmJuno.dsc/fdf
>>>>>
>>>>>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 291 
>>>>> ---
>>>>>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 365 
>>>>> -
>>>>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 317 
>>>>> -
>>>>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 401 
>>>>> --
>>>>>
>>>>> [1] https://git.linaro.org/uefi/OpenPlatformPkg.git
>>>>
>>>> Shouldn't we sync OpenPlatformPkg with the latest EDK2 versions first?
>>>
>>> Ooops.
>>>
>>> I wasn't aware of any changes in the EDK2 versions that we need to
>>> carry over.  From what I can see, there are changes in OpenPlatformPkg
>>> that are not in EDK2, but not the other way round, except this change:
>>>
>>> 660aaec  2015-12-15  ArmVExpressPkg/ArmVExpress-FVP-AArch64: run GICv3
>>> in v3 mode   [Ard Biesheuvel]
>>>
>>> The ARM Landing Team (that'll be me!) ships GICv2 .dts files for the
>>> FVP models and we don't have a plan to change to running with GICv3,
>>> except in legacy mode.  So I'd revert that change anyway until I was
>>> ready to support GICv3 properly.
>>
>> In that case, could we please leave FVP in? Unlike OpenPlatformPkg,
>> EDK2 is a reference implementation, i.e., someone looking to implement
>> something for his own platform containing a GICv3 should have a
>> reference that makes sense,
>
> I don't think that's a good approach either.  I could make GICv2/3 a
> build option in OpenPlatformPkg.  I'd even concede to making GICv3 the
> default and change my own build scripts & CI jobs to use legacy mode,
> despite...
>
>> and not some bodge that happens to work
>> because you guys are only interested in GICv2 mode anyway.
>
> Well, that's not a very nice way to put it :-P  We supported FVP
> before GICv3 was working, so we had to use GICv2.  We don't had the
> capacity to make and test the changes needed to support GICv3.

Apologies if I sounded a bit abrasive there. It's just that our
objectives are not entirely aligned here, I think. Removing GICv3
support from FVP does not improve EDK2's quality as a reference
implementation, even if it runs equally well for everyone that
actually uses it.

I produce FVP snapshots here:
http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/

that have the DTBs for all FVP flavors built in, and run equally well
on Foundation/GICv3 and Base with either GICv2 or v3 (since the GIC
memory address is not runtime configurable).

For me personally, that is useful since using FVP Base is a pain when
your uplink is dodgy (which tends to happen if you live in an RV) so I
use Foundation and only switch to Base if i have to, prefereably with
the exact same image. But I am ny no means the standard we should all
live by, of course.

I am happy to switch to OpenPlatformPkg for building those once it is
synced up with EDK2, but I'd prefer it if we don't start backing out
changes which are arguably correct just for convenience.

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


Re: [edk2] Transition to GitHub Update

2016-01-16 Thread Ard Biesheuvel
On 15 January 2016 at 22:14, Jarlstrom, Laurie
 wrote:
> To: EDK II Community
>
> This message is an update on the transition from SourceForge to GitHub for 
> EDK II development.  The schedule is currently targeting the last week of 
> January or the first week of February to perform the transition.  The 
> transition process should only take one to two days to complete.  A 
> notification message will be sent the week prior to the actual dates that the 
> repositories will be impacted.  This should provide adequate notification for 
> the scheduled down time.
> As part of this transition some documentation and process changes have been 
> required.  The updated process as well as other GitHub specific information 
> can be found on the tianocore Wiki at the link provided below.  Feedback on 
> this documentation is welcome and needed to make sure the transition is as 
> smooth as possible.
>
> https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start
>
> Please post any comments or questions related to this transition to the 
> edk2-devel mailing list or reply to the email message.
>

Hello,

Thanks for getting all of this set up.

Regarding the following line

'Commits should build / boot if possible to support use of bisect'

could we make that a bit stronger please? Breaking bisect is really
not ok, and it usually does not take that much extra work to avoid it,
as long as you are aware of it. Given that many people are new to Git,
presenting it as an opt-in feature like this does not send the right
message imo.

In fact, having some guidelines about how to avoid breaking bisect
could be helpful, especially that something like adding some temporary
code in an early patch only to remove it again at the end of the
series is perfectly ok, and highly preferred over losing
bisectability. Not everybody might expect that.

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


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

2016-06-28 Thread Ard Biesheuvel
On 25 June 2016 at 09:16, Shannon Zhao <zhaoshengl...@huawei.com> wrote:
> From: Shannon Zhao <shannon.z...@linaro.org>
>
> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
> ACPI tables through Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao <shannon.z...@linaro.org>

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

Committed as 402dde68aff9

Thanks,
Ard.

> ---
> Changes since v2:
> * add gFdtClientProtocolGuid to the [Depex]
> * make functions static
> * move XenAcpiRsdpStructurePtr to InstallXenArmTables ()
> * initialize AcpiTable and FdtClient to NULL
>
> Changes since v1:
> * move the codes into ArmVirtPkg
> * use FdtClient
> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
>   entry point since it's minor
> * use compatible string to find the DT node instead of node path
>
> If you want to test, the corresponding Xen patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v2
> ---
>  ArmVirtPkg/ArmVirtXen.dsc  |   8 +
>  ArmVirtPkg/ArmVirtXen.fdf  |   8 +
>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 244 
> +
>  .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  |  50 +
>  4 files changed, 310 insertions(+)
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a869986 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,11 @@
>
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..b1e00e5 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,14 @@ READ_LOCK_STATUS   = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c 
> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> new file mode 100644
> index 000..c6912ba
> --- /dev/null
> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> @@ -0,0 +1,244 @@
> +/** @file
> +  Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
> +
> +  Copyright (C) 2016, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +/**
> +  Get the address of Xen ACPI Root System Description Pointer (RSDP)
> +  structure.
> +
> +  @param  RsdpStructurePtr   Return pointer to RSDP structure
> +
> +  @return EFI_SUCCESSFind Xen RSDP structure successfully.
> +  @return EFI_NOT_FOUND  Don't find Xen RSDP structure.
> +  @return EFI_ABORTEDFind Xen RSDP structure, but it's not 
> integrated.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +GetXenArmAcpiRsdp (
> +  OUT   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   **RsdpPtr
> +  )
> +{
> +  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
> +  EFI_STATUS Status;
> +  FDT_CLIENT_PROTOCOL*FdtClient;
> +  CONST UINT64   *Reg;
> +  UINT32 RegElemSize, RegSize;
> +  UINT64 RegBase;
> +  UINT8  Sum;
> +
> +  RsdpStructurePtr = NULL;
> +

Re: [edk2] Instance of library class [ArmMmuLib] is not found

2016-07-22 Thread Ard Biesheuvel
On 21 July 2016 at 15:20, Haojian Zhuang  wrote:
[...]
>
>
> I think that we also need to append ArmMmuLib in
> ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf. Since ArmConfigureMmu() is
> used in MemoryInitPeim.
>

It is only used by MemoryInitPeiLib, which is used by MemoryInitPeim,
and I already added it to MemoryInitPeiLib.inf.

If you are having build problems due to this, it may be caused by the
fact that you are including MemoryInitPeiLib.c directly in
MemoryInitPeim.inf. This was fixed upstream in patch

d94a48c71a67 ArmPlatformPkg: do not fulfil MemoryInitPeiLib dependency
directly via .c file

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


Re: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO mode

2016-07-26 Thread Ard Biesheuvel
On 26 July 2016 at 03:47, Gao, Liming <liming@intel.com> wrote:
> Ard:
>   Another information. I try Steven change in 
> https://github.com/shijunjing/edk2/tree/llvm_v2. With his patch, build -p 
> OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -DSECURE_BOOT_ENABLE=TRUE -a IA32 -a X64 
> can pass build.
>

Thank you Liming. I will study Steven's patches to figure out what is
going on here.

Thanks,
Ard.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Gao, Liming
>> Sent: Monday, July 25, 2016 10:12 PM
>> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org;
>> ler...@redhat.com; leif.lindh...@linaro.org
>> Subject: Re: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO
>> mode
>>
>> Without -DSECURE_BOOT_ENABLE=TRUE, OVMF on GCC5 in LTO mode can
>> pass build.
>>
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Monday, July 25, 2016 10:04 PM
>> To: Gao, Liming <liming@intel.com>
>> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org;
>> leif.lindh...@linaro.org; ler...@redhat.com
>> Subject: Re: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO
>> mode
>>
>>
>> > On 25 jul. 2016, at 15:21, Gao, Liming wrote:
>> >
>> > Ard:
>> > After apply these patches, I try to build OvmfPkg with SECURE enable on
>> GCC5 in LTO mode.
>>
>>
>> Did you also try it without?
>>
>> > It reports build failure. Have you tried such build before?
>> >
>>
>> No I have not.
>>
>> > Build command: build -p OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -
>> DSECURE_BOOT_ENABLE=TRUE -a IA32 -a X64
>> > Build error message, seemly OpenSsl can't be linked with LTO.
>> >
>>
>> I will investigate. It indeed looks like an incompatibility with lto, I 
>> should check
>> whether Arm is affected as well.
>>
>> Thanks,
>> Ard.
>>
>> > "gcc" -o
>> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeM
>> odulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStub
>> Dxe.dll -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 -Wl,--
>> entry,_ModuleEntryPoint -u _ModuleEntryPoint -Wl,-
>> Map,/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/M
>> deModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/Security
>> StubDxe.map -Wl,-melf_x86_64,--oformat=elf64-x86-64 -Wl,--start-
>> group,@/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64
>> /MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/OUTPUT/stat
>> ic_library_files.lst,--end-group -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -
>> Wl,--
>> script=/home/hwu/work/lgao4/AllPkg/edk2/BaseTools/Scripts/GccBase.lds
>> > /tmp/cc9uBgrd.ltrans0.ltrans.o: In function `DxeImageVerificationHandler':
>> > :(.text+0x1f13): undefined reference to `malloc'
>> > :(.text+0x1f7a): undefined reference to `free'
>> > :(.text+0x1f92): undefined reference to `malloc'
>> > :(.text+0x1fb9): undefined reference to `free'
>> > :(.text+0x1fe3): undefined reference to `free'
>> > :(.text+0x2027): undefined reference to `malloc'
>> > :(.text+0x20bf): undefined reference to `free'
>> > :(.text+0x2116): undefined reference to `free'
>> > :(.text+0x212d): undefined reference to `free'
>> > :(.text+0x213a): undefined reference to `free'
>> > :(.text+0x21f7): undefined reference to `free'
>> > /tmp/cc9uBgrd.ltrans0.ltrans.o::(.text+0x2204): more undefined
>> references to `free' follow
>> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function
>> `default_realloc_ex.lto_priv.190':
>> > :(.text+0x1): undefined reference to `realloc'
>> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function
>> `default_malloc_ex.lto_priv.187':
>> > :(.text+0x6): undefined reference to `malloc'
>> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `CRYPTO_free':
>> > :(.text+0x613): undefined reference to `free'
>> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `WrapPkcs7Data':
>> > :(.text.unlikely+0x72): undefined reference to `malloc'
>> > /tmp/cc9uBgrd.ltrans17.ltrans.o: In function `OPENSSL_gmtime':
>> > :(.text+0x176a): undefined reference to `malloc'
>> > /tmp/cc9uBgrd.ltrans18.ltrans.o: In function `RSA_free':
>> > :(.text+0x123a): undefined reference to `free'
>> > /tmp/cc9uBgrd.ltrans20.ltrans.o: In function `

Re: [edk2] [PATCH v3 3/6] BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLD

2016-07-26 Thread Ard Biesheuvel
On 26 July 2016 at 09:40, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> On 2016-07-26 00:19:20, Ard Biesheuvel wrote:
>> On 25 July 2016 at 22:56, Jordan Justen <jordan.l.jus...@intel.com> wrote:
>> > I think you should make the build_rule changes in one patch, and the
>> > tools_def changes in the second. GCCLD, in this patch, will not work
>> > for using GCC as the linker.
>> >
>>
>> Not sure I understand what you mean. After his patch, GCC and GCCLD
>> are 100% equivalent, and any toolchains could use either and get the
>> exact same result, The gcc vs ld binary changes are in the next
>> patch(es)
>
> I meant that I don't think we need to make GCCLD equivalent at first.
>
> Instead, I suggest we add GCCLD with the -Wl changes, but don't set
> any toolchain to use it.
>
> Then we update the tools_def in a separate patch to make some
> toolchains use GCCLD, and at the same time change their linker flags
> to add -Wl.
>
> Basically, pull the build_rule changes into this patch from the next
> patch, and push the tools_def changes from this patch into the next
> patch.
>

GCCLD will mean 'use ld as linker' not 'use gcc as linker', and is
introduced in this patch so the legacy GCC toolchains don't need to be
updated. So the tools_def changes are appropriate here, they introduce
GCCLD and move the legacy toolchains over to use it so that subsequent
changes to the original GCC build rule family will not affect them.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] AArch64 XIP Recipe

2016-07-27 Thread Ard Biesheuvel
On 26 July 2016 at 20:00, Cohen, Eugene  wrote:
> Ard,
>
>
>> I coded this up here. Could you take a look whether this works for you, 
>> please?
>> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/commitdiff/3194d6c71014017df323ff22b1b0af819bd0e760
>
> From a build perspective it looks good, I see this:
>
>  31c:   d021adrpx1, 6000 
> 
>  320:   b9400e64ldr w4, [x19,#12]
>
> in ELF turning into this in PECOFF:
>
>   031C: 1002E721  adr x1,6000
>   0320: B9400E64  ldr w4,[x19,#0xC]
>
> I booted our platform and this change works.
>
> From a size perspective our XIP FV grows by 5.8KB changing from the tiny 
> model to the small model - it's better than both the 18KB from large and 
> 300-ish KB from small+page aligned.
>

You should be able to improve on that by adding -mcmodel=tiny to the
CCFLAGS for SEC, PEIM and PEI_CORE modules. I introduced CC_XIPFLAGS a
while ago so that we could set strict alignment for any code that
could potentially execute with the MMU off, but unfortunately, that
covers BASE as well, so the only way to do this currently is to add it
to your platform's DSC

> Thanks to you we have a number of options for how to address the XIP issue, 
> many of which work for us.  How can we capture these learnings so others can 
> benefit?  Some sort of AArch64 XIP wiki?  Which approach do you want to use 
> with edk2 reference platforms?
>

I intend to propose a patch on top of the GenFw changes to introduce
LD_XIPFLAGS, which we can set to '-z common-page-size 0x20' in
tools_def.txt for any toolchain/target combination that sets '-z
common-page-size 0x1000' (i.e., DEBUG_GCC49 but also *_CLANG35). That
way, the toolchain will be close enough to optimal for most people not
to care, and otherwise, it can be fine tuned in the platform DSC

As for documentation, patches happily accepted :-)

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


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

2016-07-13 Thread Ard Biesheuvel
On 13 July 2016 at 16:35, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 8 July 2016 at 10:42, Shi, Steven <steven@intel.com> wrote:
>> Both GCC and LLVM 3.8 64bits support new variable argument (VA)
>> intrinsics for Microsoft ABI, enable these new VA intrinsics for
>> GNUC family 64bits code build. These VA intrinsics are only
>> permitted use in 64bits code, so not use them in 32bits code build.
>> The original 32bits GNU VA intrinsics has the same calling conversion
>> as MS, so we don’t need change them.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Steven Shi <steven@intel.com>
>> ---
>>  MdePkg/Include/Base.h | 27 +--
>>  1 file changed, 25 insertions(+), 2 deletions(-)
>>  mode change 100644 => 100755 MdePkg/Include/Base.h
>>
>> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
>> old mode 100644
>> new mode 100755
>> index cbd9e55..5129b64
>> --- a/MdePkg/Include/Base.h
>> +++ b/MdePkg/Include/Base.h
>> @@ -588,9 +588,32 @@ struct _LIST_ENTRY {
>>
>>  #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
>>
>> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
>> +
>> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && !defined 
>> (MDE_CPU_IA32)
>
> This will affect all other architectures as well, so you should
> probably change the second proposition to
>
> defined(MDE_CPU_X64)
>
> instead.
>
>
>> +//
>> +// 64bits build only. Use GCC built-in macros for variable argument lists.
>> +//
>> +///
>> +/// Both GCC and LLVM 3.8 64bits support new variable argument intrinsics 
>> for Microsoft ABI
>> +///
>> +
>> +///
>> +/// Variable used to traverse the list of arguments. This type can vary by
>> +/// implementation and could be an array or structure.
>> +///
>> +typedef __builtin_ms_va_list VA_LIST;
>> +
>> +#define VA_START(Marker, Parameter)  __builtin_ms_va_start (Marker, 
>> Parameter)
>> +
>> +#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ? 
>> (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker, 
>> TYPE)))
>> +
>> +#define VA_END(Marker)   __builtin_ms_va_end (Marker)
>> +
>> +#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
>> +
>> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && defined 
>> (MDE_CPU_IA32)
>
> likewise here
>
>>  //
>> -// Use GCC built-in macros for variable argument lists.
>> +// 32bits build only. Use GCC built-in macros for variable argument lists.
>>  //
>>
>
> Note that with this change alone, I managed to build EmulatorPkg/X64
> and Ovmf/X64 successfully using '-fpic -mcmodel=small -O2' (and
> removing -DNO_BUILTIN_VA_FUNCS), using versions of GCC all the way
> back to v4.7.4, which results in much smaller binaries.

OK, that is not entirely true. To support -fpic code (but linked
without -pie) you will also need either your patch

BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

or the following hunk

"""
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -27,6 +27,16 @@
 #pragma pack()
 #endif

+#if defined(__GNUC__) && defined(__pic__)
+//
+// Mark all symbol declarations and references as hidden, meaning they will not
+// be exported from a shared library, and thus will not be subject to symbol
+// preemption. This allows the compiler to refer to symbols directly using
+// relative references rather than via the GOT, which contains absolute symbol
+// addresses that are subject to runtime relocation.
+//
+#pragma GCC visibility push (hidden)
+#endif

 #if defined(__INTEL_COMPILER)
 //
"""

Note that there is no benefit to having a GOT in a bare metal binary:
it only increases the number of absolute references, and binaries are
not shared between processes, which means there is no need to
concentrate relocatable quantities in as few pages as possible in
order to keep the remaining pages clean.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 4/4] ArmVirtPkg: add name GUIDs to FvMain instances

2016-07-12 Thread Ard Biesheuvel
On 12 July 2016 at 11:53, Laszlo Ersek <ler...@redhat.com> wrote:
> On 07/12/16 11:16, Ard Biesheuvel wrote:
>> Assign name GUIDs to the FVs that may appear in DevicePath references to
>> things like the UiApp and the UEFI Shell. This prevents these device
>> paths from changing inadvertently when the FV ends up in a different
>> memory location due to external occurrences such as, e.g., a change in
>> the amount of system memory.
>
> I didn't know (or remember) the amount of system memory might have an
> effect on this. In OvmfPkg the locations are fixed and only change when
> we change the FDF files manually.
>
> How (and where) is FVMAIN_COMPACT's file's compressed section
> decompressed in ArmVirtQemu, and ArmVirtQemuKernel?
>


To be honest, I noticed it on a bare metal platform (AMD Seattle), and
extrapolated. But as you know, AARCH64 does not distinguish between <
4 GB and >= 4GB, and so it will typically attempt to decompress it as
high up in memory as it can.

In ArmVirtQemu's case, the FV is decompressed by PEI core (in response
to a PPI invocation done by DxeIpl which looks for the DXE core image)
, and in the PrePi case (ArmVirtQemuKernel and ArmVirtXen), we use
PrePiLib in EmbeddedPkg, since we skip PEI core entirely in that case.
I'm not sure where exactly the difference lies between OVMF and
ArmVirtQemu, but I could not find any code that allocates a fixed
address to decompress FvMain.

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


[edk2] [PATCH 3/4] ArmVirtPkg: factor out Rules FDF section

2016-07-12 Thread Ard Biesheuvel
All three current ArmVirtPkg have identical [Rules] sections in their
FDF definitions, and ideally, they should remain that way. So factor
out the definitions into a separate include file, and replace the
existing definitions with !include directives.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/ArmVirtQemu.fdf   | 111 +-
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 111 +-
 ArmVirtPkg/ArmVirtRules.fdf.inc  | 123 
 ArmVirtPkg/ArmVirtXen.fdf| 111 +-
 4 files changed, 126 insertions(+), 330 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 9176cf24f105..c6a22dc018f3 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -117,113 +117,4 @@ [FV.FVMAIN_COMPACT]
 }
   }
 
-
-
-#
-# Rules are use with the [FV] section's module INF type to define
-# how an FFS file is created for a given INF file. The following Rule are the 
default
-# rules for the different module type. User can add the customized rules to 
define the
-# content of the FFS file.
-#
-
-
-
-
-# Example of a DXE_DRIVER FFS file with a Checksum encapsulation section   #
-
-#
-#[Rule.Common.DXE_DRIVER]
-#  FILE DRIVER = $(NAMED_GUID) {
-#DXE_DEPEXDXE_DEPEX   Optional 
$(INF_OUTPUT)/$(MODULE_NAME).depex
-#COMPRESS PI_STD {
-#  GUIDED {
-#PE32 PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
-#UI   STRING="$(MODULE_NAME)" Optional
-#VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
-#  }
-#}
-#  }
-#
-
-
-[Rule.Common.SEC]
-  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
-TE  TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
-  }
-
-[Rule.Common.PEI_CORE]
-  FILE PEI_CORE = $(NAMED_GUID) FIXED {
-TE TE Align = Auto  $(INF_OUTPUT)/$(MODULE_NAME).efi
-UI STRING ="$(MODULE_NAME)" Optional
-  }
-
-[Rule.Common.PEIM]
-  FILE PEIM = $(NAMED_GUID) FIXED {
- PEI_DEPEX PEI_DEPEX Optional   $(INF_OUTPUT)/$(MODULE_NAME).depex
- TE   TE Align = Auto   $(INF_OUTPUT)/$(MODULE_NAME).efi
- UI   STRING="$(MODULE_NAME)" Optional
-  }
-
-[Rule.Common.PEIM.TIANOCOMPRESSED]
-  FILE PEIM = $(NAMED_GUID) DEBUG_MYTOOLS_IA32 {
-PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
-GUIDED A31280AD-481E-41B6-95E8-127F4C984779 PROCESSING_REQUIRED = TRUE {
-  PE32  PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
-  UISTRING="$(MODULE_NAME)" Optional
-}
-  }
-
-[Rule.Common.DXE_CORE]
-  FILE DXE_CORE = $(NAMED_GUID) {
-PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
-UI   STRING="$(MODULE_NAME)" Optional
-  }
-
-[Rule.Common.UEFI_DRIVER]
-  FILE DRIVER = $(NAMED_GUID) {
-DXE_DEPEXDXE_DEPEX  Optional 
$(INF_OUTPUT)/$(MODULE_NAME).depex
-PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
-UI   STRING="$(MODULE_NAME)" Optional
-  }
-
-[Rule.Common.DXE_DRIVER]
-  FILE DRIVER = $(NAMED_GUID) {
-DXE_DEPEXDXE_DEPEX  Optional 
$(INF_OUTPUT)/$(MODULE_NAME).depex
-PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
-UI   STRING="$(MODULE_NAME)" Optional
-  }
-
-[Rule.Common.DXE_RUNTIME_DRIVER]
-  FILE DRIVER = $(NAMED_GUID) {
-DXE_DEPEXDXE_DEPEX  Optional 
$(INF_OUTPUT)/$(MODULE_NAME).depex
-PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
-UI   STRING="$(MODULE_NAME)" Optional
-  }
-
-[Rule.Common.UEFI_APPLICATION]
-  FILE APPLICATION = $(NAMED_GUID) {
-UI STRING ="$(MODULE_NAME)" Optional
-PE32   PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
-  }
-
-[Rule.Common.UEFI_DRIVER.BINARY]
-  FILE DRIVER = $(NAMED_GUID) {
-DXE_DEPEX DXE_DEPEX Optional  |.depex
-PE32  PE32|.efi
-UISTRING="$(MODULE_NAME)" Optional
-VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
-  }
-
-[Rule.Common.UEFI_APPLICATION.BINARY]
-  FILE APPLICATION = $(NAMED_GUID) {
-PE32  PE32|.efi
-UISTRING="$(MODULE_NAME)" Optional
-VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
-  }
-
-[Rule.Common.USE

[edk2] [PATCH 0/4] ArmVirtPkg: fdf cleanup

2016-07-12 Thread Ard Biesheuvel
This may be a bit premature, with Laszlo's stale boot entry removal patch
still under review, but since it addresses an issue that I had noticed
myself already, and since Ray has provided a useful suggestion to prevent
this from occurring in the future, it makes sense to simply add the
FvNameGuids to ArmVirtPkg right away. In preparation of that, some FDF
cleanup is performed, so that ArmVirtQemu and ArmVirtQemuKernel share the
same GUID for their FvMain FV, allowing their pflash varstore images to
be used interchangeably.

Ard Biesheuvel (4):
  ArmVirtPkg: align ArmVirtQemuKernel.fdf with ArmVirtQemu.fdf
  ArmVirtPkg/ArmVirtQemu: factor out shared FV.FvMain definition
  ArmVirtPkg: factor out Rules FDF section
  ArmVirtPkg: add name GUIDs to FvMain instances

 ArmVirtPkg/ArmVirtQemu.fdf   | 265 +---
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 179 +
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 261 +--
 ArmVirtPkg/ArmVirtRules.fdf.inc  | 123 +
 ArmVirtPkg/ArmVirtXen.fdf| 112 +
 5 files changed, 308 insertions(+), 632 deletions(-)
 create mode 100644 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
 create mode 100644 ArmVirtPkg/ArmVirtRules.fdf.inc

-- 
1.9.1

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


[edk2] [PATCH 2/4] ArmVirtPkg/ArmVirtQemu: factor out shared FV.FvMain definition

2016-07-12 Thread Ard Biesheuvel
The FDF definition of [FV.FvMain] is identical between ArmVirtQemu and
ArmVirtQemuKernel, and needs to remain that way. So factor it out into
a separate include file, and replace both definitions with an !include
directive.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/ArmVirtQemu.fdf   | 154 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 178 
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 154 +
 3 files changed, 180 insertions(+), 306 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index d98a01cef35f..9176cf24f105 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -82,159 +82,7 @@ [FD.QEMU_EFI]
 #
 

 
-[FV.FvMain]
-BlockSize  = 0x40
-NumBlocks  = 0 # This FV gets compressed so make it just big 
enough
-FvAlignment= 16# FV alignment and FV attributes setting.
-ERASE_POLARITY = 1
-MEMORY_MAPPED  = TRUE
-STICKY_WRITE   = TRUE
-LOCK_CAP   = TRUE
-LOCK_STATUS= TRUE
-WRITE_DISABLED_CAP = TRUE
-WRITE_ENABLED_CAP  = TRUE
-WRITE_STATUS   = TRUE
-WRITE_LOCK_CAP = TRUE
-WRITE_LOCK_STATUS  = TRUE
-READ_DISABLED_CAP  = TRUE
-READ_ENABLED_CAP   = TRUE
-READ_STATUS= TRUE
-READ_LOCK_CAP  = TRUE
-READ_LOCK_STATUS   = TRUE
-
-  INF MdeModulePkg/Core/Dxe/DxeMain.inf
-  INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
-  INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
-  INF ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
-  INF ArmVirtPkg/HighMemDxe/HighMemDxe.inf
-
-  #
-  # PI DXE Drivers producing Architectural Protocols (EFI Services)
-  #
-  INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
-  INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
-  INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
-  INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  INF 
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-!endif
-  INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-  INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
-  INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
-  INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
-  INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
-
-  #
-  # Multiple Console IO support
-  #
-  INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
-  INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
-  INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
-  INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
-  INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
-
-  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
-  INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-  INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
-
-  #
-  # FAT filesystem + GPT/MBR partitioning
-  #
-  INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
-  INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
-  INF FatPkg/EnhancedFatDxe/Fat.inf
-  INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-
-  #
-  # Platform Driver
-  #
-  INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
-  INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
-  INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
-
-  #
-  # UEFI application (Shell Embedded Boot Loader)
-  #
-  INF ShellPkg/Application/Shell/Shell.inf
-
-  #
-  # Bds
-  #
-  INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
-  INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
-  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
-  INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
-  INF MdeModulePkg/Application/UiApp/UiApp.inf
-
-  #
-  # Networking stack
-  #
-  INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
-  INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
-  INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
-  INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
-  INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
-  INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
-  INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
-  INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
-
-  #
-  # SCSI Bus and Disk Driver
-  #
-  INF MdeModulePkg/Bu

[edk2] [PATCH 4/4] ArmVirtPkg: add name GUIDs to FvMain instances

2016-07-12 Thread Ard Biesheuvel
Assign name GUIDs to the FVs that may appear in DevicePath references to
things like the UiApp and the UEFI Shell. This prevents these device
paths from changing inadvertently when the FV ends up in a different
memory location due to external occurrences such as, e.g., a change in
the amount of system memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtXen.fdf| 1 +
 2 files changed, 2 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 7bed6785d099..ad7037fe5f63 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -24,6 +24,7 @@
 

 
 [FV.FvMain]
+FvNameGuid = 64074afe-340a-4be6-94ba-91b5b4d0f71e
 BlockSize  = 0x40
 NumBlocks  = 0 # This FV gets compressed so make it just big 
enough
 FvAlignment= 16# FV alignment and FV attributes setting.
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index 653aa30b4d33..0a97bd8e07c6 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -104,6 +104,7 @@ [FD.XEN_EFI]
 

 
 [FV.FvMain]
+FvNameGuid = 4d2d8743-6337-4c3f-a1d9-7cc7efd283db
 BlockSize  = 0x40
 NumBlocks  = 0 # This FV gets compressed so make it just big 
enough
 FvAlignment= 16# FV alignment and FV attributes setting.
-- 
1.9.1

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


[edk2] [PATCH 1/4] ArmVirtPkg: align ArmVirtQemuKernel.fdf with ArmVirtQemu.fdf

2016-07-12 Thread Ard Biesheuvel
The platform ArmVirtQemuKernel is intended as an alternative for
ArmVirtQemu that only deviates in the way it is invoked by QEMU, either
from flash address 0x0 (the default ARM reset vector) or via the Linux
kernel boot protocol. So clean up a couple of discrepancies that crept
in over time, i.e., missing VirtioRngDxe and HighMemDxe, and the
conditional inclusion of the ACPI related drivers.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 4 
 1 file changed, 4 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf b/ArmVirtPkg/ArmVirtQemuKernel.fdf
index 1229e6bd43cc..dcea9771a288 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
+++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
@@ -128,6 +128,7 @@ [FV.FvMain]
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
   INF ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+  INF ArmVirtPkg/HighMemDxe/HighMemDxe.inf
 
   #
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
@@ -175,6 +176,7 @@ [FV.FvMain]
   INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
   INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
+  INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
 
   #
   # UEFI application (Shell Embedded Boot Loader)
@@ -218,11 +220,13 @@ [FV.FvMain]
   INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
   INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 
+!if $(ARCH) == AARCH64
   #
   # ACPI Support
   #
   INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
   INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
+!endif
 
   #
   # PCI support
-- 
1.9.1

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


Re: [edk2] [PATCH 1/4] ArmVirtPkg: align ArmVirtQemuKernel.fdf with ArmVirtQemu.fdf

2016-07-12 Thread Ard Biesheuvel
On 12 July 2016 at 11:33, Laszlo Ersek <ler...@redhat.com> wrote:
> On 07/12/16 11:16, Ard Biesheuvel wrote:
>> The platform ArmVirtQemuKernel is intended as an alternative for
>> ArmVirtQemu that only deviates in the way it is invoked by QEMU, either
>> from flash address 0x0 (the default ARM reset vector) or via the Linux
>> kernel boot protocol. So clean up a couple of discrepancies that crept
>> in over time, i.e., missing VirtioRngDxe and HighMemDxe, and the
>> conditional inclusion of the ACPI related drivers.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  ArmVirtPkg/ArmVirtQemuKernel.fdf | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf 
>> b/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> index 1229e6bd43cc..dcea9771a288 100644
>> --- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> +++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
>> @@ -128,6 +128,7 @@ [FV.FvMain]
>>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>>INF ArmVirtPkg/VirtioFdtDxe/VirtioFdtDxe.inf
>>INF ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
>> +  INF ArmVirtPkg/HighMemDxe/HighMemDxe.inf
>>
>>#
>># PI DXE Drivers producing Architectural Protocols (EFI Services)
>> @@ -175,6 +176,7 @@ [FV.FvMain]
>>INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>> +  INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>
>>#
>># UEFI application (Shell Embedded Boot Loader)
>> @@ -218,11 +220,13 @@ [FV.FvMain]
>>INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
>>INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>>
>> +!if $(ARCH) == AARCH64
>>#
>># ACPI Support
>>#
>>INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>>INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
>> +!endif
>>
>>#
>># PCI support
>>
>
> The first two hunks look good, but the last one doesn't seem complete.
> If you check commit 8e2efec6b206a, the "ArmVirtPkg/ArmVirtQemu.fdf"
> change was accompanied by a matching change in
> "ArmVirtPkg/ArmVirtQemu.dsc". That seems to be missing from
> "ArmVirtPkg/ArmVirtQemuKernel.dsc" after this patch. It will not cause
> build errors, but AcpiTableDxe and QemuFwCfgAcpiPlatformDxe will be
> built in vain, when building ArmVirtQemuKernel for ARM.
>

Indeed, I didn't think of that.

> I think we might want to split this patch in two -- first, add the two
> simple driver lines, then replicate 8e2efec6b206a separately (and fully)
> to ArmVirtQemuKernel. What do you think?
>

Yes, that works for me.

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


Re: [edk2] [PATCHv4 2/2] ArmJuno: Correct AXI->PCIe translation comments

2016-07-14 Thread Ard Biesheuvel
On 14 July 2016 at 15:58, Jeremy Linton  wrote:
> The AXI<->PCIe translation comments are out of date with
> respect to the code. In the first case the AXI master port
> is incorrectly called a slave. In the second case the the
> translation direction indicated for the slave port is the
> wrong direction.
>
> Correct both of these comments to reflect what the code is
> doing.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeremy Linton 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> index 0c7881d..d134cc4 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
> @@ -84,7 +84,7 @@ HWPciRbInit (
>PCIE_ROOTPORT_WRITE32 (PCIE_PCI_IDS + PCIE_PCI_IDS_CLASSCODE_OFFSET, 
> ((PLDA_BRIDGE_CCR << 8) | PCI_BRIDGE_REVISION_ID));
>
>//
> -  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
> +  // PCIE Window 0 -> AXI4 Master 0 Address Translations
>//
>TranslationTable = VEXPRESS_ATR_PCIE_WIN0;
>
> @@ -101,7 +101,7 @@ HWPciRbInit (
>ARM_JUNO_EXTRA_SYSTEM_MEMORY_SZ, PCI_ATR_TRSLID_AXIMEMORY);
>
>//
> -  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
> +  // AXI4 Slave 0 -> PCIE Window 0 Address Translations
>//
>TranslationTable = VEXPRESS_ATR_AXI4_SLV1;
>

Slave 0 or slave 1?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

2016-07-14 Thread Ard Biesheuvel
On 14 July 2016 at 16:42, Gao, Liming  wrote:
> Ard:
>   On patch 4, the visibility 'hidden' GCC pragma globally. Does it work 
> together with other mode, such as large? Or it only works with small and pic? 
> I want to clarify this change has no negative impact.

The #if checks for 'defined(__pic__)', which is only true if -fpic is
being passed on the command line. It works fine with other code
models, it only affects the compiler's decision whether to reference
symbols indirectly via the GOT.

>   On patch 5, I don't see any change for IA32 arch. is there no mode for IA32 
> arch? Here, small and pic must be enabled together, right? Otherwise, the 
> assumption is to load driver below 2G address. Have you collected size data 
> before and after this change?
>

To be honest, I know very little about the IA32 ABI, but I don't think
it has different code models, does it? Since the ELF relocations are
stripped by the PE/COFF conversion, I don't think it is necessary to
take into account that X64 and IA32 modules may interact with each
other when running on a X64 platform.

As far as the size is concerned, I get the following results building
DxeCore.efi with GCC47 (under OvmfPkgX64.dsc)

Before:

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .text PROGBITS 0240  00c0
   0001e3d0    AX   0 0 32
  [ 2] .rela.textRELA   00029528
   f360  0018   I   6 1 8
  [ 3] .data PROGBITS 0001e620  0001e4a0
   3448    WA   0 0 32
  [ 4] .rela.dataRELA   0003
   1158  0018   I   6 3 8

After:

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .text PROGBITS 0240  00c0
   0001a5a0    AX   0 0 32
  [ 2] .rela.textRELA   00025d48
   00010218  0018   I   6 1 8
  [ 3] .data PROGBITS 0001a7e0  0001a660
   3668    WA   0 0 32
  [ 4] .rela.dataRELA   00035f60
   1788  0018   I   6 3 8


So the text section shrinks by 16 KB (13%) in this case, and I got
similar results for other modules.

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


Re: [edk2] PCI performance issue

2016-07-14 Thread Ard Biesheuvel
On 14 July 2016 at 15:29, Shaveta Leekha  wrote:
> But I have not tested the code (software) on any other hardware/board.
> As I have not yet ported PCI code on any other board yet.
>

I would recommend to base your expectations not on U-Boot but on UEFI
running on a different architecture using similar network hardware.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 1/5] MdePkg: avoid __builtin_unreachable() on GCC v4.4

2016-07-14 Thread Ard Biesheuvel
GCC v4.4 does not implement __builtin_unreachable(), so avoid using
it when building with this version or earlier.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdePkg/Include/Base.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 858385828d93..7dbf9386b6b4 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -89,10 +89,11 @@ VERIFY_SIZE_OF (CHAR16, 2);
 // warnings.
 //
 #ifndef UNREACHABLE
-  #ifdef __GNUC__
+  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
 ///
 /// Signal compilers and analyzers that this call is not reachable.  It is
 /// up to the compiler to remove any code past that point.
+/// Not implemented by GCC 4.4 or earlier.
 ///
 #define UNREACHABLE()  __builtin_unreachable ()
   #elif defined (__has_feature)
-- 
2.7.4

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


[edk2] [PATCH 3/5] BaseTools/tools_def: enable O2 optimization for GCC X64 builds

2016-07-14 Thread Ard Biesheuvel
Now that we switched to the __builtin_ms_va_list VA_LIST type for
GCC/X64, we can trust the compiler to do the right thing even under
optimization, and so we can enable -O2 optimization all the way back
to GCC44.

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, 11 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2065fa34998f..3bff65b862a2 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4353,7 +4353,7 @@ 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 -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-march=i586 -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_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -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
@@ -4601,13 +4601,15 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_GCC44_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC44_X64_ASLDLINK_FLAGS   = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS) -m 
elf_x86_64
 *_GCC44_X64_ASM_FLAGS= DEF(GCC44_ASM_FLAGS) -m64 --64 -melf_x86_64
-*_GCC44_X64_CC_FLAGS = DEF(GCC44_X64_CC_FLAGS)
 *_GCC44_X64_DLINK_FLAGS  = DEF(GCC44_X64_DLINK_FLAGS)
 *_GCC44_X64_DLINK2_FLAGS = DEF(GCC44_X64_DLINK2_FLAGS)
 *_GCC44_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
 *_GCC44_X64_OBJCOPY_FLAGS= 
 *_GCC44_X64_NASM_FLAGS   = -f elf64
 
+  DEBUG_GCC44_X64_CC_FLAGS   = DEF(GCC44_X64_CC_FLAGS)
+RELEASE_GCC44_X64_CC_FLAGS   = DEF(GCC44_X64_CC_FLAGS) -O2
+
 

 #
 # GCC 4.5 - This configuration is used to compile under Linux to produce
@@ -4671,13 +4673,15 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_GCC45_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC45_X64_ASLDLINK_FLAGS   = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS) -m 
elf_x86_64
 *_GCC45_X64_ASM_FLAGS= DEF(GCC45_ASM_FLAGS) -m64 --64 -melf_x86_64
-*_GCC45_X64_CC_FLAGS = DEF(GCC45_X64_CC_FLAGS)
 *_GCC45_X64_DLINK_FLAGS  = DEF(GCC45_X64_DLINK_FLAGS)
 *_GCC45_X64_DLINK2_FLAGS = DEF(GCC45_X64_DLINK2_FLAGS)
 *_GCC45_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
 *_GCC45_X64_OBJCOPY_FLAGS= 
 *_GCC45_X64_NASM_FLAGS   = -f elf64
 
+  DEBUG_GCC45_X64_CC_FLAGS   = DEF(GCC45_X64_CC_FLAGS)
+RELEASE_GCC45_X64_CC_FLAGS   = DEF(GCC45_X64_CC_FLAGS) -O2
+
 

 #
 # GCC 4.6 - This configuration is used to compile under Linux to produce
@@ -4750,7 +4754,7 @@ RELEASE_GCC46_IA32_CC_FLAGS   = 
DEF(GCC46_IA32_CC_FLAGS) -Os -Wno-unused-but
 *_GCC46_X64_NASM_FLAGS   = -f elf64
 
   DEBUG_GCC46_X64_CC_FLAGS   = DEF(GCC46_X64_CC_FLAGS)
-RELEASE_GCC46_X64_CC_FLAGS   = DEF(GCC46_X64_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC46_X64_CC_FLAGS   = DEF(GCC46_X64_CC_FLAGS) -O2 
-Wno-unused-but-set-variable
 
 ##
 # GCC46 ARM definitions
@@ -4855,7 +4859,7 @@ RELEASE_GCC47_IA32_CC_FLAGS   = 
DEF(GCC47_IA32_CC_FLAGS) -Os -Wno-unused-but
 *_GCC47_X64_NASM_FLAGS   = -f elf64
 
   DEBUG_GCC47_X64_CC_FLAGS   = DEF(GCC47_X64_CC_FLAGS)
-RELEASE_GCC47_X64_CC_FLAGS   = DEF(GCC47_X64_CC_FLAGS) 
-Wno-unused-but-set-variable
+RELEASE_GCC47_X64_CC_FLAGS   = DEF(GCC47_X64_CC_FLAGS) -O2 
-Wno-unused-but-set-variable
 
 ##
 # GCC47 ARM definitions
@@ -4987,7 +4991,7 @@ RELEASE_GCC48_IA32_CC_FLAGS   = 
DEF(GCC48_IA32_CC_FLAGS) -Os -Wno-unused-but
 *_GCC48_X64_NASM_FLAGS   = -f elf64
 
   DEBUG_GCC48_X64_CC_FLAGS   = DEF(GCC48_X64_CC_FLAGS)
-RELEASE_GCC48_X64_CC_FLAGS   = DEF

[edk2] [PATCH 4/5] MdePkg X64: force 'hidden' visibility when building with -fpic

2016-07-14 Thread Ard Biesheuvel
When building position independent (PIC) ELF objects, the GCC compiler
assumes that each symbol with external linkage may potentially end up
being exported from a shared library, which means that each of those
symbols may be subject to symbol preemption, i.e., the executable
linking to the shared library at runtime may override symbols exported
by the shared library, and every internal reference held by the shared
library itself *must* be made to point to the overridden version instead.

For this reason, PIC code symbol references always go via the Global
Offset Table (GOT), even if the code in question references symbols that
are defined in the same compilation unit. The GOT refers to each symbol
by absolute address, and so each entry is subject to runtime relocation.

Since not every symbol with external linkage is ultimately exported from
a shared library, the GCC compiler allows control over symbol visibility
using attributes, command line arguments and pragmas, where 'hidden'
means that the symbol is only referenced by the shared library itself.
Due to the poor hygiene in EDK2 regarding the use of the 'static'
modifier, many symbols that are local to their compilation unit end up
being referenced indirectly via the GOT when building PIC code.

In UEFI, there are no shared libraries and so there is no need to deal
with symbol preemption, and we can mark every symbol reference 'hidden'.
The only method that applies to all symbol definitions as well as
declarations is the #pragma. So set the visibility 'hidden' pragma when
building PIC code for X64 using GCC.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdePkg/Include/X64/ProcessorBind.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MdePkg/Include/X64/ProcessorBind.h 
b/MdePkg/Include/X64/ProcessorBind.h
index 705104af062a..96df78fca07d 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -27,6 +27,16 @@
 #pragma pack()
 #endif
 
+#if defined(__GNUC__) && defined(__pic__)
+//
+// Mark all symbol declarations and references as hidden, meaning they will not
+// be exported from a shared library, and thus will not be subject to symbol
+// preemption. This allows the compiler to refer to symbols directly using
+// relative references rather than via the GOT, which contains absolute symbol
+// addresses that are subject to runtime relocation.
+//
+#pragma GCC visibility push (hidden)
+#endif
 
 #if defined(__INTEL_COMPILER)
 //
-- 
2.7.4

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


[edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

2016-07-14 Thread Ard Biesheuvel
This series is not an attempt to steal Steven's thunder. I was merely
inspired by some of the changes he is proposing for GCC 5 and Clang
support, which I noticed would be applicable to older versions of GCC
as well.

The first patch fixes the issue that __builtin_unreachable() is not
implemented by GCC 4.4 or earlier.

Patch #2 is Steven's patch to switch to the flavor of VA_LIST that is
explicitly modeled after the MS implementation. This by itself is an
improvement, since the open coded implementation that performs arithmetic
on the address of explicit arguments to obtain the variadic arguments is
fragile and difficult to maintain, and should be best avoided.

Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
I tested this change with both Ovmf and EmulatorPkg built in various ways
and with various versions, with the caveat that I did not always use a matching
binutils (i.e., of the same era). Since the issues this series deal with are
all code generation issues, I think this is reasonable, but more testing would
be appreciated.

Patch #4 applies the visibility 'hidden' GCC pragma globally. Please refer to
the commit log for the motivation.

Patch #5 switches GCC/X64 to the PIC small code model, which results in smaller
code.

Ard Biesheuvel (4):
  MdePkg: avoid __builtin_unreachable() on GCC v4.4
  BaseTools/tools_def: enable O2 optimization for GCC X64 builds
  MdePkg X64: force 'hidden' visibility when building with -fpic
  BaseTools/tools_def: switch GCC/X64 to the PIC small model

Shi, Steven (1):
  MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build

 BaseTools/Conf/tools_def.template  | 18 +++-
 MdePkg/Include/Base.h  | 29 +++-
 MdePkg/Include/X64/ProcessorBind.h | 10 +++
 3 files changed, 49 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 MdePkg/Include/Base.h

-- 
2.7.4

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


[edk2] [PATCH 5/5] BaseTools/tools_def: switch GCC/X64 to the PIC small model

2016-07-14 Thread Ard Biesheuvel
The ordinary small code model for x86_64 cannot be used in UEFI, since
it assumes the executable is loaded in the first 2 GB of memory.
Therefore, we use the large model instead, which can execute anywhere,
but uses absolute 64-bit wide quantities for all symbol references,
which is costly in terms of code size.

So switch to the PIC small code model, this uses 32-bit relative
references where possible, but does not make any assumptions about the
load address (i.e., all absolute symbol references are 64-bits wide).
Note that, due to the 'hidden' visibility pragma introduced in an
earlier patch, there is no need for the EDK2 build system to deal with
GOT related ELF relocation types.

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 3bff65b862a2..529a29402968 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4353,7 +4353,7 @@ 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 -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-march=i586 -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))" -mno-red-zone 
-Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
+DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone 
-Wno-address -mcmodel=small -fpic -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
-- 
2.7.4

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


Re: [edk2] PCI performance issue

2016-07-14 Thread Ard Biesheuvel
On 14 July 2016 at 15:05, Shaveta Leekha  wrote:
> Hi,
>
>
>
>
>
> I have been working on PCI controller driver performance (Root Bridge) for
> my ARMv8 platform. I had integrated my PciHostBridgeDxe code with
> MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource
> allocation and Root bridge IO protocol, as used in some other existing PCI
> root bridge driver.
>
>
>
> My concern here is that:
>
>
>
> Tftp using PCI interface is painfully slow. It takes around 10 mins to
> transfer a 30MB file over PCI NIC card using Tftp
>

How much time does it take on other hardware? Did you try it on your PC?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 2/5] MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build

2016-07-14 Thread Ard Biesheuvel
From: "Shi, Steven" <steven@intel.com>

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven@intel.com>

[ardb: update CPP logic so that the change only applies to X64]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdePkg/Include/Base.h | 26 
 1 file changed, 26 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
old mode 100644
new mode 100755
index 7dbf9386b6b4..876d4a34262e
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -590,6 +590,30 @@ struct _LIST_ENTRY {
 #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
 
 #elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
+
+#ifdef MDE_CPU_X64
+//
+// X64 only. Use MS ABI version of GCC built-in macros for variable argument 
lists.
+//
+///
+/// Both GCC and LLVM 3.8 for X64 support new variable argument intrinsics for 
Microsoft ABI
+///
+
+///
+/// Variable used to traverse the list of arguments. This type can vary by
+/// implementation and could be an array or structure.
+///
+typedef __builtin_ms_va_list VA_LIST;
+
+#define VA_START(Marker, Parameter)  __builtin_ms_va_start (Marker, Parameter)
+
+#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ? 
(TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker, 
TYPE)))
+
+#define VA_END(Marker)   __builtin_ms_va_end (Marker)
+
+#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
+
+#else
 //
 // Use GCC built-in macros for variable argument lists.
 //
@@ -608,6 +632,8 @@ typedef __builtin_va_list VA_LIST;
 
 #define VA_COPY(Dest, Start) __builtin_va_copy (Dest, Start)
 
+#endif
+
 #else
 ///
 /// Variable used to traverse the list of arguments. This type can vary by
-- 
2.7.4

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


Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

2016-07-14 Thread Ard Biesheuvel
On 14 July 2016 at 15:16, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> This series is not an attempt to steal Steven's thunder. I was merely
> inspired by some of the changes he is proposing for GCC 5 and Clang
> support, which I noticed would be applicable to older versions of GCC
> as well.
>
> The first patch fixes the issue that __builtin_unreachable() is not
> implemented by GCC 4.4 or earlier.
>
> Patch #2 is Steven's patch to switch to the flavor of VA_LIST that is
> explicitly modeled after the MS implementation. This by itself is an
> improvement, since the open coded implementation that performs arithmetic
> on the address of explicit arguments to obtain the variadic arguments is
> fragile and difficult to maintain, and should be best avoided.
>
> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
> I tested this change with both Ovmf and EmulatorPkg built in various ways
> and with various versions, with the caveat that I did not always use a 
> matching
> binutils (i.e., of the same era). Since the issues this series deal with are
> all code generation issues, I think this is reasonable, but more testing would
> be appreciated.
>
> Patch #4 applies the visibility 'hidden' GCC pragma globally. Please refer to
> the commit log for the motivation.
>
> Patch #5 switches GCC/X64 to the PIC small code model, which results in 
> smaller
> code.
>

Code can be found here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/gcc-x64-opt
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [StdLib] Fails to compile with the latest version of Xcode/clang due to new compiler diagnostic.

2016-07-21 Thread Ard Biesheuvel
On 21 July 2016 at 17:38, Andrew Fish <af...@apple.com> wrote:
>
>> On Jul 21, 2016, at 4:00 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> 
>> wrote:
>>
>> On 20 July 2016 at 23:09, Andrew Fish <af...@apple.com> wrote:
>>> It looks like clang has added a warning to detect infinite recursion and 
>>> I'm seeing the failure here:
>>>
>>> https://github.com/tianocore/edk2/blob/master/StdLib/LibC/StdLib/Environs.c#L123
>>> void
>>> _Exit(int status)
>>> {
>>>  gMD->ExitValue = status;  // Save our exit status.  Allows a 
>>> status of 0.
>>>  longjmp(gMD->MainExit, 0x55); // Get out of here.  longjmp can't 
>>> return 0. Use 0x55 for a non-zero value.
>>>
>>> #ifdef __GNUC__
>>>  _Exit(status);/* Keep GCC happy - never reached */
>>> #endif
>>> }
>>>
>>> This is the compiler warning.
>>>
>>> error: all paths through this function will call itself 
>>> [-Werror,-Winfinite-recursion]
>>>
>>> I fixed by replacing the infinite recursion with UNREACHABLE() but I'm not 
>>> sure what the rules are changing this chunk of code?
>>>
>>
>> UNREACHABLE() resolves to an empty string on GCC44 [or it will as soon
>> as my patch that fixes that is merged, since 4.4 does not implement
>> __builtin_unreachable()]
>>
>> The correct thing would be to set __attribute__((noreturn)) on the
>> longjmp() prototype [if __GNUC__], but it would be interesting to
>> understand what GCC was unhappy about to begin with.
>>
>
> Ard,
>
> It looks like _Exit() is __noreturn and longjmp() is not. If I remove the 
> UNREACHABLE() then clang warns:
> error: function declared 'noreturn' should not return 
> [-Werror,-Winvalid-noreturn]
>

OK, thanks for clearing that up.

> I noticed that a while (1); also fixes the issue. I wonder if  UNREACHABLE() 
> should map to while(1) if __builtin_unreachable() does not exist.
>

AFAIU it amounts to the same thing, i.e., the compiler will infer that
the code after the while (1) is not reachable. The only question is if
that is always the case, for each version of each compiler that
#defines __GNUC__

> I'm not sure longjmp() is noreturn as it is really a non local goto. Maybe it 
> is a legacy issue as marking it as noreturn could break existing code (You 
> could start getting unreachable code warnings)?
>

longjmp() is the mentioned in the __noreturn documentation, and it
seems to me that 'returning' in this context is defined in relation to
whether the stack frame is reused after the call. For the same reason,
setjmp() is mentioned in the docs of the returns_twice attribute.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 2/2] BaseTools GCC: add support for GCC/X64 and GCC/AARCH64 in LTO mode

2016-07-22 Thread Ard Biesheuvel
On 22 July 2016 at 10:38, Gao, Liming  wrote:
> Ard:
>   I have some comments on GCC5 DLINK PATH definition. *_GCC5_*_DLINK_PATH 
>  = $(EDK_TOOLS_PATH)/Scripts/lto-ld-wrapper.py
> 1) It directly points to python script. In OS, python script need be trigged 
> by python execute.
> 2) Most windows users directly use the binary base tools. They may not 
> install python, and not directly use python script in build process. This 
> patch still breaks windows GCC5 build.
>
>   So, I suggest:
> 1) Add lto-ld-wrapper script in BaseTools/BinWrappers/PosixLike to call 
> $(EDK_TOOLS_PATH)/Scripts/lto-ld-wrapper.py for Linux
> 2) Freeze $(EDK_TOOLS_PATH)/Scripts/lto-ld-wrapper.py to 
> $(EDK_TOOLS_PATH)/Scripts/lto-ld-wrapper.exe for Windows
> 3) Define *_GCC5_*_DLINK_PATH  = 
> ENV(LTO_LD_PREFIX)lto-ld-wrapper, then Windows user can configure 
> LTO_LD_PREFIX evn to use it.
>
>  And, for lto-ld-wrapper.py script, it should print the full command before 
> execute it so that user knows the real commands
>

OK.

>  Last, on GCC5 DLINK and DLINK_FLAGS. There are two styles to define them. I 
> prefer style 2 to keep DLINK_FALGS without changes.
> 1)
> *_GCC5_*_DLINK_PATH  = ENV(LTO_LD_PREFIX)lto-ld-wrapper
> *_GCC5_IA32_DLINK_FLAGS  = --cc "DEF(GCC5_IA32_PREFIX)gcc" 
> DEF(GCC5_IA32_X64_DLINK_FLAGS) -m elf_i386 --oformat=elf32-i386
>
> 2)
> *_GCC5_*_DLINK_PATH  = ENV(LTO_LD_PREFIX)lto-ld-wrapper --cc 
> "DEF(GCC5_IA32_PREFIX)gcc"
> *_GCC5_IA32_DLINK_FLAGS  = DEF(GCC5_IA32_X64_DLINK_FLAGS) -m elf_i386 
> --oformat=elf32-i386
>

That does not work, unfortunately. The build rule puts quotes around
the path, and so the --cc argument becomes part of argument 0, e.g.,

/bin/sh: 1: lto-ld-wrapper --cc aarch64-linux-gnu-gcc: not found

due to


"$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group
$(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) --end-group
$(DLINK2_FLAGS)
"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 2/2] BaseTools GCC: add support for GCC/X64 and GCC/AARCH64 in LTO mode

2016-07-22 Thread Ard Biesheuvel
On 22 July 2016 at 23:19, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> I think the subject should include be something like "add GCC5
> toolchain for X64/AARCH64 with LTO support".
>
> On 2016-07-18 05:09:15, Ard Biesheuvel wrote:
>> This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and
>> AARCH64. Due to the fact that the GCC project switched to a new
>> numbering scheme where the first digit is now incremented for every
>> major release, the new toolchain is simply called 'GCC5', and is
>> intended to support all GCC v5.x releases.
>>
>> Note that this requires the use of an wrapper script, since the GCC
>> toolchain family usually invokes the linker directly, whereas LTO
>> requires GCC to be invoked with the linker arguments decorated with
>> -Wl,xxx prefixes.
>
> Does it require the wrapper script? Steven's GCC5 toolchain didn't
> have it. Also, I was able to convert the GCC49 toolchain to invoke gcc
> for the linker, rather than ld. Like Steven's GCC5, I had to add -Wl
> to various flags. Based on this, I was wondering if we could just
> convert all of the GCC toolchains to invoke gcc for linking.
>

Steven's patches introduced a new build rule family, which I would
like to avoid, since it would make GCC:xxx [BuildOptions] sections
mutually incompatible between GCC44 - GCC49 and GCC5 and later, which
would probably result in some packages being left behind, and new
packages not bothering to add support for GCC49 and older. Packages
supporting both would need to add explicit rules for each GCCx
version, which is also not great for maintainability. As it turns out,
we don't have that many DLINK or DLINK2 flags in our various .DSC and
.INF files, but the ones we do have need to be fixed up at the same
time that the build rule is updated.

So if nobody is opposed to having a flag day, and switch over all of
Tianocore to use the 'gcc' executable as the linker, and fix up all
the fallout in a single patch, I'm up for it.

-- 
Ard.


>>
>> Since IA32 and X64 enable compiler optimizations (-Os) for both DEBUG
>> and RELEASE builds, LTO support is equally enabled for both targets.
>> On ARM and AARCH64, DEBUG builds are not optimized, and so the LTO
>> optimizations are only enabled for RELEASE.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  BaseTools/Conf/tools_def.template   | 156 
>>  BaseTools/Scripts/lto-ld-wrapper.py |  39 +
>>  2 files changed, 195 insertions(+)
>>
>> diff --git a/BaseTools/Conf/tools_def.template 
>> b/BaseTools/Conf/tools_def.template
>> index f9b26fad44de..56bcf04690d4 100644
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -197,6 +197,9 @@ DEFINE GCC48_X64_PREFIX= ENV(GCC48_BIN)
>>  DEFINE GCC49_IA32_PREFIX   = ENV(GCC49_BIN)
>>  DEFINE GCC49_X64_PREFIX= ENV(GCC49_BIN)
>>
>> +DEFINE GCC5_IA32_PREFIX= ENV(GCC5_BIN)
>> +DEFINE GCC5_X64_PREFIX = ENV(GCC5_BIN)
>> +
>>  DEFINE UNIX_IASL_BIN   = ENV(IASL_PREFIX)iasl
>>  DEFINE WIN_ASL_BIN_DIR = C:\ASL
>>  DEFINE WIN_IASL_BIN= DEF(WIN_ASL_BIN_DIR)\iasl.exe
>> @@ -4450,6 +4453,27 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS= 
>> DEF(GCC48_AARCH64_DLINK2_FLAGS)
>>  DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
>>  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>>
>> +DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -flto
>> +DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto
>> +DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
>> +DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
>> +DEFINE GCC5_IA32_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto
>> +DEFINE GCC5_IA32_DLINK2_FLAGS= DEF(GCC49_IA32_DLINK2_FLAGS)
>> +DEFINE GCC5_X64_DLINK_FLAGS  = DEF(GCC49_X64_DLINK_FLAGS)
>> +DEFINE GCC5_X64_DLINK2_FLAGS = DEF(GCC49_X64_DLINK2_FLAGS)
>> +DEFINE GCC5_ASM_FLAGS= DEF(GCC49_ASM_FLAGS)
>> +DEFINE GCC5_ARM_ASM_FLAGS= DEF(GCC49_ARM_ASM_FLAGS)
>> +DEFINE GCC5_AARCH64_ASM_FLAGS= DEF(GCC49_AARCH64_ASM_FLAGS)
>> +DEFINE GCC5_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS)
>> +DEFINE GCC5_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS)
>> +DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
>> +DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(

Re: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO mode

2016-07-25 Thread Ard Biesheuvel

> On 25 jul. 2016, at 15:21, Gao, Liming <liming@intel.com> wrote:
> 
> Ard:
> After apply these patches, I try to build OvmfPkg with SECURE enable on GCC5 
> in LTO mode.


Did you also try it without?

> It reports build failure. Have you tried such build before?
> 

No I have not.

> Build command: build -p OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 
> -DSECURE_BOOT_ENABLE=TRUE -a IA32 -a X64
> Build error message, seemly OpenSsl can't be linked with LTO.
> 

I will investigate. It indeed looks like an incompatibility with lto, I should 
check whether Arm is affected as well.

Thanks,
Ard.

> "gcc" -o 
> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStubDxe.dll
>  -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 
> -Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint 
> -Wl,-Map,/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStubDxe.map
>  -Wl,-melf_x86_64,--oformat=elf64-x86-64 
> -Wl,--start-group,@/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/OUTPUT/static_library_files.lst,--end-group
>  -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 
> -Wl,--script=/home/hwu/work/lgao4/AllPkg/edk2/BaseTools/Scripts/GccBase.lds
> /tmp/cc9uBgrd.ltrans0.ltrans.o: In function `DxeImageVerificationHandler':
> :(.text+0x1f13): undefined reference to `malloc'
> :(.text+0x1f7a): undefined reference to `free'
> :(.text+0x1f92): undefined reference to `malloc'
> :(.text+0x1fb9): undefined reference to `free'
> :(.text+0x1fe3): undefined reference to `free'
> :(.text+0x2027): undefined reference to `malloc'
> :(.text+0x20bf): undefined reference to `free'
> :(.text+0x2116): undefined reference to `free'
> :(.text+0x212d): undefined reference to `free'
> :(.text+0x213a): undefined reference to `free'
> :(.text+0x21f7): undefined reference to `free'
> /tmp/cc9uBgrd.ltrans0.ltrans.o::(.text+0x2204): more undefined references to 
> `free' follow
> /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `default_realloc_ex.lto_priv.190':
> :(.text+0x1): undefined reference to `realloc'
> /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `default_malloc_ex.lto_priv.187':
> :(.text+0x6): undefined reference to `malloc'
> /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `CRYPTO_free':
> :(.text+0x613): undefined reference to `free'
> /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `WrapPkcs7Data':
> :(.text.unlikely+0x72): undefined reference to `malloc'
> /tmp/cc9uBgrd.ltrans17.ltrans.o: In function `OPENSSL_gmtime':
> :(.text+0x176a): undefined reference to `malloc'
> /tmp/cc9uBgrd.ltrans18.ltrans.o: In function `RSA_free':
> :(.text+0x123a): undefined reference to `free'
> /tmp/cc9uBgrd.ltrans20.ltrans.o: In function `qsort':
> :(.text+0x1368): undefined reference to `malloc'
> :(.text+0x13bc): undefined reference to `malloc'
> :(.text+0x13b4): undefined reference to `free'
> /tmp/cc9uBgrd.ltrans27.ltrans.o: In function 
> `CRYPTO_realloc_clean.constprop.153':
> :(.text+0x20e): undefined reference to `free'
> /tmp/cc9uBgrd.ltrans27.ltrans.o:(.data.rel.ro.local+0x578): undefined 
> reference to `free'
> /usr/bin/ld: 
> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStubDxe.dll:
>  protected symbol `realloc' isn't defined
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> make: *** 
> [/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStubDxe.dll]
>  Error 1
> 
> 
> build.py...
> : error 7000: Failed to execute command
> make tbuild 
> [/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe]
> 
> 
> build.py...
> : error F002: Failed to build module
> /home/hwu/work/lgao4/AllPkg/edk2/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  [X64, GCC5, DEBUG]
> 
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Saturday, July 23, 2016 5:03 PM
>> To: edk2-devel@lists.01.org; ler...@redhat.com; Gao, Liming
>> ; Shi, Steven ; Zhu,
>> Yonghong ; Justen, Jordan L
>> 
>> Cc: leif.lindh...@linaro.org; Ard Biesheuvel
>> Subject: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO mode
>> 
>> This v3 to introduce GCC5 is now a 6 piece series, including some
>> preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
>> to switch to using 'g

Re: [edk2] AArch64 XIP Recipe

2016-07-25 Thread Ard Biesheuvel


> On 25 jul. 2016, at 18:28, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> 
>> On 25 July 2016 at 18:23, Cohen, Eugene <eug...@hp.com> wrote:
>> Doing some git archaeology, I suspect that stuff started to go bad for us
>> around this commit:
>> 
>> 
>> 
>> Revision: f37d891c1b870b294964adf65f619a661700fcab
>> 
>> Author: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> 
>> Date: 3/25/2016 5:33:28 AM
>> 
>> Message:
>> 
>> BaseTools AARCH64: move DEBUG GCC49 to the small code model
>> 
>> 
>> 
>> When building AARCH64 platforms that include a Shell binary built from
>> 
>> source, we run into trouble when using the tiny code model for DEBUG
>> 
>> builds. The reason is that the Shell binary built in DEBUG mode exceeds
>> 
>> the 1 MB range of the ADR instruction, so anything that gets pulled into
>> 
>> the final link of the Shell binary either needs to be built with the small
>> 
>> or large model, or needs to be sorted in some way to put the ADR references
>> 
>> close to their targets.
>> 
>> 
>> 
>> The rationale with this commit was that not only does the shell itself need
>> to use the small model (to address the 1MB displacement limitation of the
>> ADR instruction) but every library it pulls in must as well.  In our testing
>> before this commit we did not see a problem, what did you see (if you can
>> remember)?
> 
> The Shell failed to link due to the fact that the BASE libraries it
> depends on were built with the tiny model
> 
>> 
>> 
>> But any time the small memory model is used the common page size is set to
>> 4KB per the requirement stated in this change to BaseTools Elf64Convert.c:
>> 
>> 
>> 
>> Revision: 24d610e67752ac0325c7027e2fea2f8f2ff110e2
>> 
>> Author: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> 
>> Date: 8/10/2015 1:55:18 AM
>> 
>> Message:
>> 
>> BaseTools/GenFw: allow AArch64 tiny and small code model relocations
>> 
>> 
>> 
>> The AArch64 small C model makes extensive use of ADRP/ADD and
>> 
>> ADRP/{LDR,STR} pairs to emit PC-relative symbol references with
>> 
>> a +/- 4 GB range. Since the relocation pair splits the relative
>> 
>> offset into a relative page offset and an absolute offset into
>> 
>> a 4 KB page, we need to take extra care to ensure that the target
>> 
>> of the relocation preserves its alignment relative to a 4 KB
>> 
>> alignment boundary.
>> 
>> 
>> 
>> So since the shell requires all libraries to be built in the small memory
>> model and all small memory model components must have 4KB alignment, this
>> means that any component shared between XIP and the shell will get a 4KB
>> alignment treatment.  As discussed before this just eats up flash/sram space
>> in XIP regions since the FVs get padded out to meet this requirement.  This
>> results in an untenable situation.
> 
> Indeed.  The Shell in RELEASE mode builds fine with the tiny model
> though. Since the Shell is the only problematic module (afaik), it
> would suffice to simply build the shell components in RELEASE mode
> unconditionally, assuming that you are not interested in debugging the
> shell and your platform at the same time.
> 

Alternatively, you could add -mcmodel=large to the CC_XIPFLAGS, which allows 
you to set -z common-page-size 0x20 for SEC , PEIM and PEICORE modules


> 
>> 
>> 
>> As I look at the history of this, this looks like a limitation in GCC where
>> it doesn't emit the proper relocations for the page offset so as a
>> workaround the page relationship of the code and data must be preserved
>> across image conversion and relocation.  If this is fixed in GCC then can't
>> we just let the relocations fix this?  If so, is it too outrageous to
>> suggest fixing the linker?
> 
> This is not a toolchain bug, but an ISA problem, and so it is not
> going away, unfortunately.
> 
> -- 
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] AArch64 XIP Recipe

2016-07-25 Thread Ard Biesheuvel
On 25 July 2016 at 21:25, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>
>
>> On 25 jul. 2016, at 18:28, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>>
>>> On 25 July 2016 at 18:23, Cohen, Eugene <eug...@hp.com> wrote:
>>> Doing some git archaeology, I suspect that stuff started to go bad for us
>>> around this commit:
>>>
>>>
>>>
>>> Revision: f37d891c1b870b294964adf65f619a661700fcab
>>>
>>> Author: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>>
>>> Date: 3/25/2016 5:33:28 AM
>>>
>>> Message:
>>>
>>> BaseTools AARCH64: move DEBUG GCC49 to the small code model
>>>
>>>
>>>
>>> When building AARCH64 platforms that include a Shell binary built from
>>>
>>> source, we run into trouble when using the tiny code model for DEBUG
>>>
>>> builds. The reason is that the Shell binary built in DEBUG mode exceeds
>>>
>>> the 1 MB range of the ADR instruction, so anything that gets pulled into
>>>
>>> the final link of the Shell binary either needs to be built with the small
>>>
>>> or large model, or needs to be sorted in some way to put the ADR references
>>>
>>> close to their targets.
>>>
>>>
>>>
>>> The rationale with this commit was that not only does the shell itself need
>>> to use the small model (to address the 1MB displacement limitation of the
>>> ADR instruction) but every library it pulls in must as well.  In our testing
>>> before this commit we did not see a problem, what did you see (if you can
>>> remember)?
>>
>> The Shell failed to link due to the fact that the BASE libraries it
>> depends on were built with the tiny model
>>
>>>
>>>
>>> But any time the small memory model is used the common page size is set to
>>> 4KB per the requirement stated in this change to BaseTools Elf64Convert.c:
>>>
>>>
>>>
>>> Revision: 24d610e67752ac0325c7027e2fea2f8f2ff110e2
>>>
>>> Author: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>>
>>> Date: 8/10/2015 1:55:18 AM
>>>
>>> Message:
>>>
>>> BaseTools/GenFw: allow AArch64 tiny and small code model relocations
>>>
>>>
>>>
>>> The AArch64 small C model makes extensive use of ADRP/ADD and
>>>
>>> ADRP/{LDR,STR} pairs to emit PC-relative symbol references with
>>>
>>> a +/- 4 GB range. Since the relocation pair splits the relative
>>>
>>> offset into a relative page offset and an absolute offset into
>>>
>>> a 4 KB page, we need to take extra care to ensure that the target
>>>
>>> of the relocation preserves its alignment relative to a 4 KB
>>>
>>> alignment boundary.
>>>
>>>
>>>
>>> So since the shell requires all libraries to be built in the small memory
>>> model and all small memory model components must have 4KB alignment, this
>>> means that any component shared between XIP and the shell will get a 4KB
>>> alignment treatment.  As discussed before this just eats up flash/sram space
>>> in XIP regions since the FVs get padded out to meet this requirement.  This
>>> results in an untenable situation.
>>
>> Indeed.  The Shell in RELEASE mode builds fine with the tiny model
>> though. Since the Shell is the only problematic module (afaik), it
>> would suffice to simply build the shell components in RELEASE mode
>> unconditionally, assuming that you are not interested in debugging the
>> shell and your platform at the same time.
>>
>
> Alternatively, you could add -mcmodel=large to the CC_XIPFLAGS, which allows 
> you to set -z common-page-size 0x20 for SEC , PEIM and PEICORE modules
>

OK, sorry for the monologue, but I just had an idea: we could build
everything with the small model, and convert ADRP instructions to ADR
instructions in GenFw if the section alignment < 4 KB. This will cause
build failures if this conversion is not possible due to the fact that
the binary exceeds 1 MB, but this means we only need to set the 4 KB
page size for modules where this can reasonably be expected (i.e.,
UEFI_APPLICATION modules) Everything else will be just as small as the
small model.

I will cook something up, but don't expect anything before next week.

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


Re: [edk2] [PATCH v2 2/2] BaseTools GCC: add support for GCC/X64 and GCC/AARCH64 in LTO mode

2016-07-23 Thread Ard Biesheuvel
On 23 July 2016 at 03:34, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> On 2016-07-22 14:46:54, Ard Biesheuvel wrote:
>> On 22 July 2016 at 23:19, Jordan Justen <jordan.l.jus...@intel.com> wrote:
>> > I think the subject should include be something like "add GCC5
>> > toolchain for X64/AARCH64 with LTO support".
>> >
>> > On 2016-07-18 05:09:15, Ard Biesheuvel wrote:
>> >> This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and
>> >> AARCH64. Due to the fact that the GCC project switched to a new
>> >> numbering scheme where the first digit is now incremented for every
>> >> major release, the new toolchain is simply called 'GCC5', and is
>> >> intended to support all GCC v5.x releases.
>> >>
>> >> Note that this requires the use of an wrapper script, since the GCC
>> >> toolchain family usually invokes the linker directly, whereas LTO
>> >> requires GCC to be invoked with the linker arguments decorated with
>> >> -Wl,xxx prefixes.
>> >
>> > Does it require the wrapper script? Steven's GCC5 toolchain didn't
>> > have it. Also, I was able to convert the GCC49 toolchain to invoke gcc
>> > for the linker, rather than ld. Like Steven's GCC5, I had to add -Wl
>> > to various flags. Based on this, I was wondering if we could just
>> > convert all of the GCC toolchains to invoke gcc for linking.
>> >
>>
>> Steven's patches introduced a new build rule family, which I would
>> like to avoid, since it would make GCC:xxx [BuildOptions] sections
>> mutually incompatible between GCC44 - GCC49 and GCC5 and later, which
>> would probably result in some packages being left behind, and new
>> packages not bothering to add support for GCC49 and older. Packages
>> supporting both would need to add explicit rules for each GCCx
>> version, which is also not great for maintainability. As it turns out,
>> we don't have that many DLINK or DLINK2 flags in our various .DSC and
>> .INF files, but the ones we do have need to be fixed up at the same
>> time that the build rule is updated.
>>
>> So if nobody is opposed to having a flag day, and switch over all of
>> Tianocore to use the 'gcc' executable as the linker, and fix up all
>> the fallout in a single patch, I'm up for it.
>>
>
> My first choice would be to convert all the toolchains to use gcc for
> linking. I'm not certain it will work for all toolchains though.
>
> My second choice would be to just add another build rule family. I
> think it is less of a hassle than a new wrapper tool. (The issues
> Liming raises...)
>

Yes, using a wrapper script is a concern. I think adding a build rule
family is the best option, but I would prefer to add one in a way that
does not split GCC44 - GCC49 and CLANG35 on the one hand and GCC5 and
up on the other. So I will rewrite this to move the 'legacy' GCC
toolchains to a cloned GCCLD build rule family, and apply subsequent
changes to move to 'gcc' as the linker to GCC44 and up
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO mode

2016-07-23 Thread Ard Biesheuvel
This v3 to introduce GCC5 is now a 6 piece series, including some
preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
to switch to using 'gcc' as the linker. This allows us to get rid of
the wrapper script to marshall ld arguments in order to make them
understandable by gcc, which is fragile and likely to cause problems in
the future.

Since there appears to be a natural split between the 'legacy' GCC
toolchains UNIXGCC, ELFGCC, and CYGGCC[xASL], both in term of supported
architectures [IA32, X64, IPF] vs [IA32, X64, ARM, AARCH64], and in
terms of maintenance, these toolchains are not moved to using 'gcc' as
the linker, and instead, a new BUILDRULEFAMILY is introduced called GCCLD
that will retain the old behavior.

The result is that GCC5 can align much more closely with its predecessors,
making the expected maintenance burden of supporting GCC back to v4.4
much lower.

Changes since v2:
- add license headers to LTO glue files for ARM and AARCH64 (#5)
- get rid of lto-ld-wrapper script

Ard Biesheuvel (6):
  BaseTools CLANG35: drop problematic use-movt and save-temps options
  ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note
sections
  BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into
GCCLD
  BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
  ArmPkg: add prebuilt glue binaries for GCC5 LTO support
  BaseTools GCC: add support for GCC v5.x in LTO mode

 ArmPkg/GccLto/liblto-aarch64.a  | Bin 0 -> 1016 bytes
 ArmPkg/GccLto/liblto-aarch64.s  |  27 ++
 ArmPkg/GccLto/liblto-arm.a  | Bin 0 -> 2096 bytes
 ArmPkg/GccLto/liblto-arm.s  |  61 
 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |   2 +-
 ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds  |   3 +
 BaseTools/Conf/build_rule.template  |  31 +-
 BaseTools/Conf/tools_def.template   | 344 ++--
 EmulatorPkg/Unix/Host/Host.inf  |   6 +-
 9 files changed, 366 insertions(+), 108 deletions(-)
 create mode 100644 ArmPkg/GccLto/liblto-aarch64.a
 create mode 100644 ArmPkg/GccLto/liblto-aarch64.s
 create mode 100644 ArmPkg/GccLto/liblto-arm.a
 create mode 100644 ArmPkg/GccLto/liblto-arm.s

-- 
2.7.4

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


[edk2] [PATCH v3 3/6] BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLD

2016-07-23 Thread Ard Biesheuvel
Before we can make non-backward compatible changes to the GCC build rules
regarding the use of the 'gcc' binary as the linker, clone the existing
GCC build rules into a 'GCCLD' build rule family, and move the legacy
toolchains UNIXGCC, CYGGCC, CYGGCCxASL and ELFGCC over to it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 BaseTools/Conf/build_rule.template | 28 ++--
 BaseTools/Conf/tools_def.template  |  4 +++
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 91bcc1828cb5..3fea4f456118 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -130,7 +130,7 @@
 <Command.MSFT, Command.INTEL>
 "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-<Command.GCC, Command.RVCT>
+<Command.GCC, Command.GCCLD, Command.RVCT>
 # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
 "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
 
@@ -156,7 +156,7 @@
 <Command.MSFT, Command.INTEL>
 "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-<Command.GCC, Command.RVCT>
+<Command.GCC, Command.GCCLD, Command.RVCT>
 # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
 "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
 "$(SYMRENAME)" $(SYMRENAME_FLAGS) ${dst}
@@ -171,7 +171,7 @@
 
 $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 
-
+<Command.GCC, Command.GCCLD>
 "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -o ${dst} $(INC) ${src}
 
 [C-Header-File]
@@ -187,7 +187,7 @@
 <InputFile.MSFT, InputFile.INTEL, InputFile.RVCT>
 ?.asm, ?.Asm, ?.ASM
 
-
+<InputFile.GCC, InputFile.GCCLD>
 ?.S, ?.s
 
 
@@ -201,7 +201,7 @@
 Trim --source-code --convert-hex --trim-long -o 
${d_path}(+)${s_base}.iii ${d_path}(+)${s_base}.i
 "$(ASM)" /Fo${dst} $(ASM_FLAGS) /I${s_path} $(INC) 
${d_path}(+)${s_base}.iii
 
-<Command.GCC, Command.RVCT>
+<Command.GCC, Command.GCCLD, Command.RVCT>
 "$(PP)" $(PP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i
 Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii 
${d_path}(+)${s_base}.i
 # For RVCTCYGWIN ASM_FLAGS must be first to work around pathing issues
@@ -265,7 +265,7 @@
 <Command.MSFT, Command.INTEL>
 "$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)
 
-
+<Command.GCC, Command.GCCLD>
 "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
 
 
@@ -291,7 +291,7 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST)
 
-
+<Command.GCC, Command.GCCLD>
 "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
@@ -319,7 +319,7 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
-
+<Command.GCC, Command.GCCLD>
 "$(DLINK)" $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 
 
@@ -346,7 +346,7 @@
 $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
 -$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 -$(CP) $(DEBUG_DIR)(+)*.pdb $(OUTPUT_DIR) 
-
+<Command.GCC, Command.GCCLD>
 $(CP) ${src} $(DEBUG_DIR)(+)$(MODULE_NAME).debug
 $(OBJCOPY) --strip-unneeded -R .eh_frame ${src}
 
@@ -402,7 +402,7 @@
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
 
-
+<Command.GCC, Command.GCCLD>
 Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i 
$(INC_LIST) ${src}
 "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
@@ -423,7 +423,7 @@
 "$(ASLDLINK)" /OUT:$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
 
-
+<Command.GCC, Command.GCCLD>
 "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) 
$(ASLCC_FLAGS) $(INC) ${src}
 

[edk2] [PATCH v3 4/6] BaseTools GCC: use 'gcc' as the linker command for GCC44 and later

2016-07-23 Thread Ard Biesheuvel
To accommodate upcoming GCCx toolchain versions that require 'gcc' to
be used as the linker in order to support LTO, switch GCC44 and later
(including CLANG35) to a new DLINK build rule that invokes 'gcc' as the
linker instead of 'ld'. Since gcc expects its command line arguments in
a different format, and expects arguments that it needs to pass to the
linker to be prefixed with '-Wl,', this involves changes to most of the
DLINK_FLAGS definitions in tools_def.template, as well as some changes to
module .INF files that set their own linker options.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |   2 +-
 BaseTools/Conf/build_rule.template  |  11 +-
 BaseTools/Conf/tools_def.template   | 170 ++--
 EmulatorPkg/Unix/Host/Host.inf  |   6 +-
 4 files changed, 97 insertions(+), 92 deletions(-)

diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
index a4ea5a05b652..5e706934f69f 100755
--- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
+++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
@@ -107,4 +107,4 @@ [Pcd]
   gArmTokenSpaceGuid.PcdFvBaseAddress
 
 [BuildOptions]
-  GCC:*_*_*_DLINK_FLAGS = -pie -T $(MODULE_DIR)/Scripts/PrePi-PIE.lds
+  GCC:*_*_*_DLINK_FLAGS = -pie -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 3fea4f456118..eb4ae749fda5 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -291,7 +291,11 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST)
 
-<Command.GCC, Command.GCCLD>
+
+"$(DLINK)" -o ${dst} $(DLINK_FLAGS) 
-Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)
+"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
+
+
 "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
@@ -319,7 +323,10 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
-<Command.GCC, Command.GCCLD>
+
+"$(DLINK)" $(DLINK_FLAGS) 
-Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)
+
+
 "$(DLINK)" $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 
 
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8a04e38e1288..10ac21e42c8f 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4329,14 +4329,14 @@ DEFINE GCC_ARM_CC_FLAGS= 
DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi
 DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
-DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
+DEFINE GCC_DLINK2_FLAGS_COMMON = 
-Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 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_AARCH64_DLINK_COMMON= -Wl,--emit-relocs -nostdlib 
-Wl,--gc-sections -u $(IMAGE_ENTRY_POINT) 
-Wl,-e,$(IMAGE_ENTRY_POINT),-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z 
common-page-size=0x20
 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_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_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) 
-Wl,--entry,ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
+DEFINE GCC_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) 
-Wl,--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 -M

[edk2] [PATCH v3 2/6] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note sections

2016-07-23 Thread Ard Biesheuvel
Newer versions of ld automatically emit .gnu.hash and .note.gnu.build-id
sections, which are not listed in the linker script, and will end up
breaking the build with an allocation conflict, e.g.,

  /usr/bin/aarch64-linux-gnu-ld: section .note.gnu.build-id loaded at
[,0023] overlaps section .text loaded at
[,00017dbf]

Since we don't require or care about these sections, update the linker
script so that they are discarded. Note that this involves emitting the
.note.gnu.build-id section into a non-allocatable segment to prevent the
linker from noticing that it is being discarded (and subsequently
complaining about it)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds 
b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
index 832ad1474468..44df7840adfd 100644
--- a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
+++ b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
@@ -30,8 +30,11 @@ SECTIONS
 PROVIDE(__reloc_end = .);
   }
 
+  .note (INFO) : { *(.note.gnu.build-id) }
+
   /DISCARD/ : {
 *(.note.GNU-stack)
+*(.gnu.hash)
 *(.gnu_debuglink)
 *(.interp)
 *(.dynamic)
-- 
2.7.4

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


[edk2] [PATCH v3 6/6] BaseTools GCC: add support for GCC v5.x in LTO mode

2016-07-23 Thread Ard Biesheuvel
This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and
AARCH64. Due to the fact that the GCC project switched to a new
numbering scheme where the first digit is now incremented for every
major release, the new toolchain is simply called 'GCC5', and is
intended to support all GCC v5.x releases.

Since IA32 and X64 enable compiler optimizations (-Os) for both DEBUG
and RELEASE builds, LTO support is equally enabled for both targets.
On ARM and AARCH64, DEBUG builds are not optimized, and so the LTO
optimizations are only enabled for RELEASE.

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 10ac21e42c8f..241cc2531762 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -197,6 +197,9 @@ DEFINE GCC48_X64_PREFIX= ENV(GCC48_BIN)
 DEFINE GCC49_IA32_PREFIX   = ENV(GCC49_BIN)
 DEFINE GCC49_X64_PREFIX= ENV(GCC49_BIN)
 
+DEFINE GCC5_IA32_PREFIX= ENV(GCC5_BIN)
+DEFINE GCC5_X64_PREFIX = ENV(GCC5_BIN)
+
 DEFINE UNIX_IASL_BIN   = ENV(IASL_PREFIX)iasl
 DEFINE WIN_ASL_BIN_DIR = C:\ASL
 DEFINE WIN_IASL_BIN= DEF(WIN_ASL_BIN_DIR)\iasl.exe
@@ -4452,6 +4455,27 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS= 
DEF(GCC48_AARCH64_DLINK2_FLAGS)
 DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
 DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 
+DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -flto
+DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto
+DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
+DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
+DEFINE GCC5_IA32_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto
+DEFINE GCC5_IA32_DLINK2_FLAGS= DEF(GCC49_IA32_DLINK2_FLAGS)
+DEFINE GCC5_X64_DLINK_FLAGS  = DEF(GCC49_X64_DLINK_FLAGS)
+DEFINE GCC5_X64_DLINK2_FLAGS = DEF(GCC49_X64_DLINK2_FLAGS)
+DEFINE GCC5_ASM_FLAGS= DEF(GCC49_ASM_FLAGS)
+DEFINE GCC5_ARM_ASM_FLAGS= DEF(GCC49_ARM_ASM_FLAGS)
+DEFINE GCC5_AARCH64_ASM_FLAGS= DEF(GCC49_AARCH64_ASM_FLAGS)
+DEFINE GCC5_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS)
+DEFINE GCC5_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS)
+DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
+DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -flto
+DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS)
+DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) -flto
+DEFINE GCC5_AARCH64_DLINK2_FLAGS = DEF(GCC49_AARCH64_DLINK2_FLAGS)
+DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS)
+DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
+
 

 #
 # Unix GCC And Intel Linux ACPI Compiler
@@ -5186,6 +5210,140 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
DEF(GCC49_AARCH64_DLINK_FLAGS)
 
 

 #
+# GCC 5 - This configuration is used to compile under Linux to produce
+# PE/COFF binaries using GCC 5
+#
+
+*_GCC5_*_*_FAMILY= GCC
+
+*_GCC5_*_MAKE_PATH   = DEF(GCC5_IA32_PREFIX)make
+*_GCC5_*_*_DLL   = ENV(GCC5_DLL)
+*_GCC5_*_ASL_PATH= DEF(UNIX_IASL_BIN)
+
+*_GCC5_*_PP_FLAGS= DEF(GCC_PP_FLAGS)
+*_GCC5_*_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS)
+*_GCC5_*_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS)
+*_GCC5_*_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS)
+*_GCC5_*_APP_FLAGS   =
+*_GCC5_*_ASL_FLAGS   = DEF(IASL_FLAGS)
+*_GCC5_*_ASL_OUTFLAGS= DEF(IASL_OUTFLAGS)
+
+##
+# GCC5 IA32 definitions
+##
+*_GCC5_IA32_OBJCOPY_PATH = DEF(GCC5_IA32_PREFIX)objcopy
+*_GCC5_IA32_CC_PATH  = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_SLINK_PATH   = DEF(GCC5_IA32_PREFIX)gcc-ar
+*_GCC5_IA32_DLINK_PATH   = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_ASLDLINK_PATH= DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_ASM_PATH = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_PP_PATH  = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_VFRPP_PATH   = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_ASLCC_PATH   = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_ASLPP_PATH   = DEF(GCC5_IA32_PREFIX)gcc
+*_GCC5_IA32_RC_PATH  = DEF(GCC5_IA32_PREFIX)objcopy
+
+*_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto
+*_GCC5_IA32_ASLDLINK

[edk2] [PATCH v3 1/6] BaseTools CLANG35: drop problematic use-movt and save-temps options

2016-07-23 Thread Ard Biesheuvel
Some versions of Clang fail on every input file when using the
-save-temps options, and produce the following helpful error message:

  :0: error: Undefined temporary symbol

Simply dropping the option for CLANG35 is the simplest way around this,
since the value of storing .i and .s files is dubious anyway.

Also, drop the arm-use-movt option, which does not appear to be
supported anymore by more recent versions of clang.

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 847b9f729f29..b36a19314215 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4325,8 +4325,8 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
-fno-strict-aliasing -
 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) -mlittle-endian 
-mabi=aapcs -fno-short-enums -save-temps -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
-DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -save-temps -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
+DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
+DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
@@ -4384,7 +4384,7 @@ 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 
-mword-relocations
+DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector 
-mword-relocations -save-temps
 DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) 
--oformat=elf32-littlearm
 DEFINE GCC46_ARM_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
--defsym=PECOFF_HEADER_SIZE=0x220
 DEFINE GCC46_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_ASLDLINK_FLAGS) 
--oformat=elf32-littlearm
@@ -4401,7 +4401,7 @@ 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(GCC44_ALL_CC_FLAGS) -mcmodel=large DEF(GCC_AARCH64_CC_FLAGS)
+DEFINE GCC47_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) -mcmodel=large DEF(GCC_AARCH64_CC_FLAGS) -save-temps
 DEFINE GCC47_AARCH64_CC_XIPFLAGS = DEF(GCC_AARCH64_CC_XIPFLAGS)
 DEFINE GCC47_ARM_DLINK_FLAGS = DEF(GCC46_ARM_DLINK_FLAGS)
 DEFINE GCC47_ARM_DLINK2_FLAGS= DEF(GCC46_ARM_DLINK2_FLAGS)
@@ -4443,7 +4443,7 @@ 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= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_AARCH64_CC_FLAGS)
+DEFINE GCC49_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_AARCH64_CC_FLAGS) -save-temps
 DEFINE GCC49_AARCH64_CC_XIPFLAGS = DEF(GCC48_AARCH64_CC_XIPFLAGS)
 DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS)
 DEFINE GCC49_ARM_DLINK2_FLAGS= DEF(GCC48_ARM_DLINK2

[edk2] [PATCH v3 5/6] ArmPkg: add prebuilt glue binaries for GCC5 LTO support

2016-07-23 Thread Ard Biesheuvel
GCC in LTO mode interoperates poorly with non-standard libraries that
provide implementations of compiler intrinsics such as memcpy/memset
or the stack protector entry points. Such libraries need to be built
in non-LTO mode, and then referenced explicitly on the linker command
line using a -plugin-opt=-pass-through=-lxxx linker option.

However, if these intrinsics are also referenced directly, the LTO
version of the code will be pulled in, and will happily satisfy all
other references to the same symbol.

So add a pair of glue libraries, for ARM and AARCH64, that reference
the known intrinsics. Since the binaries live under ArmPkg directly,
we can reference them in tools_def.txt. Under LD garbage collection,
the object itself will be pruned, and so will the intrinsics that end
up unused by the module.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 ArmPkg/GccLto/liblto-aarch64.a | Bin 0 -> 1016 bytes
 ArmPkg/GccLto/liblto-aarch64.s |  27 +
 ArmPkg/GccLto/liblto-arm.a | Bin 0 -> 2096 bytes
 ArmPkg/GccLto/liblto-arm.s |  61 
 4 files changed, 88 insertions(+)

diff --git a/ArmPkg/GccLto/liblto-aarch64.a b/ArmPkg/GccLto/liblto-aarch64.a
new file mode 100644
index 
..2ab00238f0dad882abf08a1fb9623c9cdea9f17b
GIT binary patch
literal 1016
zcmbu7!M8btcV>pmaJb3R#Pab@Ovb0qUG$GwJk&}<*)yMErJh~su
zhGA(FBh#ci^V@G{X8(NLKR`dGgNxR5Xq8|a14Nj;_ot@whUR;}*D0W|+#ne8)
z+crcqtbp?TKuy$d;Fk^js)5sWPGwPMt2G8wSV~i4b+$;e`67MRugg8~@}{d?w$pJf
z%hU2Z13wYMF8ko8f}aWQH5;VNy0m%Ghc<?O^ORa42Zb{|ZYEm;}M9QPwkz0*h
zki8>ef}gYSE})e*bOFvFk<j^57EYNXKak(^fcXvc@Z~)5d^m*lCr*Hz|6PAkvlcbK
oxX>*EVPSp5Eivz1-~TrQyaBwMaQ{8W!rrlD%!Td{2n*}~0;u;a`v3p{

literal 0
HcmV?d1

diff --git a/ArmPkg/GccLto/liblto-aarch64.s b/ArmPkg/GccLto/liblto-aarch64.s
new file mode 100644
index ..45000d327758
--- /dev/null
+++ b/ArmPkg/GccLto/liblto-aarch64.s
@@ -0,0 +1,27 @@
+//
+// Copyright (c) 2016, Linaro Ltd. All rights reserved.
+//
+// This program and the accompanying materials are licensed and made available 
under
+// the terms and conditions of the BSD License that accompanies this 
distribution.
+// The full text of the license may be found at
+// http://opensource.org/licenses/bsd-license.php.
+//
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+
+//
+// GCC in LTO mode interoperates poorly with non-standard libraries that
+// provide implementations of compiler intrinsics such as memcpy/memset
+// or the stack protector entry points.
+//
+// By referencing these functions from a non-LTO object that can be passed
+// to the linker via the -plugin-opt=-pass-through=-lxxx options, the
+// intrinsics are included in the link in a way that allows them to be
+// pruned again if no other references to them exist.
+//
+
+   .long   memcpy - .
+   .long   memset - .
+   .long   __stack_chk_fail - .
+   .long   __stack_chk_guard - .
diff --git a/ArmPkg/GccLto/liblto-arm.a b/ArmPkg/GccLto/liblto-arm.a
new file mode 100644
index 
..d811c09573a35ea87a8002ecf01be18e1c6e7fd3
GIT binary patch
literal 2096
zcmd6o%WKq76vn?XQ*C|Js#WW|YOD1@u(oJH7cHm=wjd(Xg%C3{sS}#eGD-SEunQLz
zT?o1mx)E36>ti;!4n^e}Mi6u3h<^n@J{fT<Fp}Ouq9w_nvbfNlqSKoxD~mm5{X(
zhR`D5^G4ItF=}K8T}U0-`2R^Kc5yYX=T>}_x@dNmx{6!*W2si#P63O*VzW?IBihqh
z=)ig*pojKb#bw326`xc*toV}R>x!op%I;^}JZ=gW^w$zbO8u_=n=3
zihn6C7jA)^cemm`#e<4%#TOM%D88Zij$&7Fpm;^`6UFO_-zdgF4UQAVZgtkF)@Pj=
z*ALnp_Y=1vL)@s|sQDwQ6*Mh*7aYIlFNiybaLxo6PTG16rQHlllhBAv-k>#u2@Sol
zI=`G}CPrQiN;tRR(ak(*AdNItn6xb{AamTrttlr6972!~lYGJ?`uh4`8leFjDu
zR1H=l|GXG+(@3h}e9gF`ML(|A$Jm)#Ny{9*kb6fYIz6K#U~GZXiE;<`AQQJZh#Ex*
zvPafpsg(EM+QeEU%F9+!7AJXjt<6BM=oX+)l${4fw*md4-N1n8cCac_8FW^32XIbw
zCm?m%V%-}PWwOhnEHdMwdw?sVdjY8%7AKh$-3Qzh-4EOrJpf1@u{il%(L=yJ(ZfJZ
z^axNF?FRzUqrklAF(4K_4lIdsu@6KCfmP8Hz#~x>xiwL4;;HB<;F;)Y;DzWJUhHT&
zjNJ+~ZlqeztcDlZv9}b%uDP)byAnmP`PA5M95?(*5_=I7{9EHzOij<eVx#1jh0yHv
z<B{-Nm!6|^Pj~Rl*~wdJ;>*-d{<&4d*_Y!hx!AINvPBvHw{hmarpIg2NWNZUrI#!p
wAAvlV^sI41<6<;hHcoUy=A?e-|05l;7C8giM-Tt9*KBPx@rv+1OG3`f-+dwCzyJUM

literal 0
HcmV?d1

diff --git a/ArmPkg/GccLto/liblto-arm.s b/ArmPkg/GccLto/liblto-arm.s
new file mode 100644
index ..bc16320a46c0
--- /dev/null
+++ b/ArmPkg/GccLto/liblto-arm.s
@@ -0,0 +1,61 @@
+//
+// Copyright (c) 2016, Linaro Ltd. All rights reserved.
+//
+// This program and the accompanying materials are licensed and made available 
under
+// the terms and conditions of the BSD License that accompanies this 
distribution.
+// The full text of the license may be found at
+// http://opensource.org/licenses/bsd-license.php.
+//
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+// WITHOUT WARR

Re: [edk2] Question on eMMC and SD driver

2016-07-22 Thread Ard Biesheuvel
On 22 July 2016 at 08:34, Haojian Zhuang  wrote:
> This feature isn't implemented yet. The plan is to cache the updated
> variable. When reset command is detected, write back variables from volatile
> area to eMMC device. If there's an unexpected power off or hang, the update
> variables will be lost.
>

This is not the way I would like to see it. I have some ideas on how
this could be implemented, both on the firmware and on the OS side,
but let's take that off line.

However, as a general note, we need to address this on the spec side,
i.e., how to support a platform whose only non-variable storage is
behind a controller that is shared with the OS at runtime.

@Haojian: for now, there is no point in continuing this discussion on
edk2-devel.

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


Re: [edk2] [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode

2016-07-29 Thread Ard Biesheuvel
On 29 July 2016 at 06:47, Gao, Liming <liming@intel.com> wrote:
> Ard:
>   Thanks for your update. I have some comments for them.
> 1) It uses GCC as Link for GCC44-GCC49. Have you done verification on them? I 
> verify GCC49 in OVMFIa32X64 platform. It works.

Yes, I tested all of them.

> 2) After this change, how to append new link option in platform DSC? Use 
> style -Wl, ?

It depends. Some options (like -z) don't need it, but others do.

> 3) I see GCC5 uses gcc-ar as its SLINK, and GCC49 uses ar as its SLINK. Is 
> gcc-ar required only by LTO?

Yes

> 4) Before GCC49 optimization, GCC49 means GCC49 or later, GCC5 can work with 
> GCC49 tool chain configuration. But now, I configure gcc to point to GCC5, 
> and build OVMF with GCC49 tool chain, it reports GenFw failure. I expect GCC5 
> work with GCC49 and GCC5 tool chain both. GCC49 for no lto, GCC5 for lto. I 
> know Steven has provided the patch to fix this GenFw issue.
>
> GenFw: ERROR 3000: Invalid
>   
> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>  unsupported ELF EM_X86_64 relocation 0x9.
> GenFw: ERROR 3000: Invalid
>   
> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>  unsupported ELF EM_X86_64 relocation 0x9.
> GenFw: ERROR 3000: Invalid
>

Which GCC version are you using?


>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Wednesday, July 27, 2016 7:14 PM
>> To: edk2-devel@lists.01.org; ler...@redhat.com; Gao, Liming
>> <liming@intel.com>; Shi, Steven <steven@intel.com>; Zhu,
>> Yonghong <yonghong@intel.com>; Justen, Jordan L
>> <jordan.l.jus...@intel.com>
>> Cc: leif.lindh...@linaro.org; Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Subject: [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode
>>
>> This v4 to introduce GCC5 is now a 7 piece series, including some
>> preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
>> to switch to using 'gcc' as the linker. This allows us to get rid of
>> the wrapper script to marshall ld arguments in order to make them
>> understandable by gcc, which is fragile and likely to cause problems in
>> the future.
>>
>> Since there appears to be a natural split between the 'legacy' GCC
>> toolchains UNIXGCC, ELFGCC, and CYGGCC[xASL], both in term of supported
>> architectures [IA32, X64, IPF] vs [IA32, X64, ARM, AARCH64], and in
>> terms of maintenance, these toolchains are not moved to using 'gcc' as
>> the linker, and instead, a new BUILDRULEFAMILY is introduced called GCCLD
>> that will retain the old behavior.
>>
>> The result is that GCC5 can align much more closely with its predecessors,
>> making the expected maintenance burden of supporting GCC back to v4.4
>> much lower.
>>
>> Changes since v3:
>> - like Steven does in his GCC5LTO patch, add -fno-builtin to IA32 and X64
>>   CC_FLAGS; this addresses a build issue reported by Liming
>> - add -Os the the linker flags as well, for AARCH64 this does not seem to
>> make
>>   a difference, but it is arguably correct since the LTO processing at link
>>   time involves code generation as well
>> - add Laszlo's ack to #2
>> - new patch #6 to omit the autogenerated build-id from the PE/COFF binary
>>
>> Changes since v2:
>> - add license headers to LTO glue files for ARM and AARCH64 (#5)
>> - get rid of lto-ld-wrapper script
>>
>> Ard Biesheuvel (7):
>>   BaseTools CLANG35: drop problematic use-movt and save-temps options
>>   ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note
>> sections
>>   BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into
>> GCCLD
>>   BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
>>   ArmPkg: add prebuilt glue binaries for GCC5 LTO support
>>   BaseTools GCC: drop GNU notes section from EFI image
>>   BaseTools GCC: add support for GCC v5.x in LTO mode
>>
>>  ArmPkg/GccLto/liblto-aarch64.a  | Bin 0 -> 1016 bytes
>>  ArmPkg/GccLto/liblto-aarch64.s  |  27 ++
>>  ArmPkg/GccLto/liblto-arm.a  | Bin 0 -> 2096 bytes
>>  ArmPkg/GccLto/liblto-arm.s  |  61 
>>  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |   2 +-
>>  ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds  |   3 +
>>  BaseTools/Conf/build_rule.template  |  31 +-
>>  BaseTools/Conf/

Re: [edk2] [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode

2016-07-29 Thread Ard Biesheuvel
On 29 July 2016 at 08:09, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 29 July 2016 at 06:47, Gao, Liming <liming@intel.com> wrote:
>> Ard:
>>   Thanks for your update. I have some comments for them.
>> 1) It uses GCC as Link for GCC44-GCC49. Have you done verification on them? 
>> I verify GCC49 in OVMFIa32X64 platform. It works.
>
> Yes, I tested all of them.
>
>> 2) After this change, how to append new link option in platform DSC? Use 
>> style -Wl, ?
>
> It depends. Some options (like -z) don't need it, but others do.
>
>> 3) I see GCC5 uses gcc-ar as its SLINK, and GCC49 uses ar as its SLINK. Is 
>> gcc-ar required only by LTO?
>
> Yes
>
>> 4) Before GCC49 optimization, GCC49 means GCC49 or later, GCC5 can work with 
>> GCC49 tool chain configuration. But now, I configure gcc to point to GCC5, 
>> and build OVMF with GCC49 tool chain, it reports GenFw failure. I expect 
>> GCC5 work with GCC49 and GCC5 tool chain both. GCC49 for no lto, GCC5 for 
>> lto. I know Steven has provided the patch to fix this GenFw issue.
>>
>> GenFw: ERROR 3000: Invalid
>>   
>> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>>  unsupported ELF EM_X86_64 relocation 0x9.
>> GenFw: ERROR 3000: Invalid
>>   
>> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>>  unsupported ELF EM_X86_64 relocation 0x9.
>> GenFw: ERROR 3000: Invalid
>>
>
> Which GCC version are you using?
>

I cannot reproduce this with gcc version 5.4.0 20160609 (Ubuntu
5.4.0-6ubuntu1~16.04.1)

In any case, I think we should merge Steven's patch that adds handling
to the relocation types to GenFw. The issue is only that having a GOT
does not make a lot of sense for UEFI executables, since it forces a
symbol reference to be absolute, which uses more space in the code,
but also in the .reloc section. The visibility pragma I introduced for
GCC4x was intended to prevent GOT based relocations from being
emitted.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

2016-07-31 Thread Ard Biesheuvel
On 1 August 2016 at 06:39, Shi, Steven  wrote:
>> >
>> > That was not my point. With your code, how many
>> > EFI_IMAGE_REL_BASED_DIR64 fixups are added to the .reloc section for
>> > the GOT entry of 'n'?
>> >
>> > int n;
>> > int f () { return n; }
>> > int g () { return n; }
>> > int h () { return n; }
>
> [Steven]: If the above global " n " need GOTPCREL type relocation. It should 
> need only once EFI_IMAGE_REL_BASED_DIR64 fixups in my code.
>

Yes, I believe so. I think it would be possible to sort the .reloc
section and eliminate duplicates, but doing this correctly is
non-trivial in any case.

>>
>> I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations.
>> Reading the x86_64 ABI docs, it appears that these may refer to
>> instructions that have been modified by the linker. In that case, how
>> do we deal with the relocation? Also, according to the doc, mov
>> instructions may be emitted by the linker in some cases that are only
>> valid in the lowest 2 GB of the address space.
>>
> [Steven]: Frankly to say, the x86_64 ABI docs is only good for compiler 
> domain developer and not very good for other domain developers to understand 
> it.
> My overall understanding for these different relocation type is like this: 
> compiler generate PIC code with different "level of indirection to all global 
> data and function references in the code." And these different level of 
> indirection is implemented through GOT and PLT structure with different 
> addressing calculation pattern. The different calculation patterns are the 
> different relocation types which are defined  by  x86_64 ABI Table 4.9. We 
> don't need worry about how compiler correctly generate code to work with 
> these relocation types, we just need correctly understand their addressing 
> calculation pattern.
>
> The GOTPCRELX/REX_GOTPCRELX has the same calculation definition in x86_64 ABI 
> Table 4.9 as "G + GOT + A - P". So, I assume their difference is not in the 
> relocation calculation pattern, but how to co-work with specific instructions 
> to finish these calculation in a hardware optimized way.
>

No, that is not what these are for. The special types mark
instructions that can be converted by the linker into simpler
sequences if the symbol turns out to be in the same module. From the
doc:

mov foo@GOTPCREL(%rip), %reg

could be converted by the linker into

lea foo(%rip), %reg

if the reference to 'foo' is satisfied by a non-preemptible local
definition. This is a useful optimization, since it eliminates a
memory load. The problem is that we cannot recalculate such
relocations in GenFw without checking whether the linker has applied
this optimization or not.

> One important thing worthy to mention that our gcc link script (GccBase.lds) 
> has forced the GOT related sections , e.g. '.got', '.got.plt' , into .text 
> section. So, all the GOT relocation fixup target .text section in fact.
>
> I find below article help me a lot to understand some PIC simple relocation 
> types. Hope it also can help you. I wish Eli, the author of below articles, 
> could be invited as one author of x86_64 ABI spec, which will surely make the 
> spec be more readable to other domain developers. :)
> Position Independent Code (PIC) in shared libraries
> http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
> Position Independent Code (PIC) in shared libraries on x64
> http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64
>
>>
>> All in all, I think supporting GOT based relocations is a can of
>> worms, and I would prefer to get rid of them completely if we can
>> (i.e., using hidden visibility even for LTO, I have a fix for that I
>> will sent out separately)
>>
> [Steven]: I agree we should try to avoid generating complex relocation type 
> code for Uefi. But to make Uefi code build more portable to various version 
> compilers and linker, I think it is still necessary to support these GOT 
> based relocations.
> I've tested the GenFw new relocation types support with both GCC5/GCC49 (with 
> default visibility) and CLANG38 in my branch in before. It can works. I 
> suggest we could just keep these code there for reference.
>

The fact that it works does not make it safe. Having multiple fixups
for the same symbol in the .reloc section is a problem, and so is
reapplying GOTPCRELX to places where the original instruction has been
replaced by the linker.

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


Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 08:13, Shi, Steven  wrote:
>> >>
>> >> I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations.
>> >> Reading the x86_64 ABI docs, it appears that these may refer to
>> >> instructions that have been modified by the linker. In that case, how
>> >> do we deal with the relocation? Also, according to the doc, mov
>> >> instructions may be emitted by the linker in some cases that are only
>> >> valid in the lowest 2 GB of the address space.
>> >>
>> > [Steven]: Frankly to say, the x86_64 ABI docs is only good for compiler
>> domain developer and not very good for other domain developers to
>> understand it.
>> > My overall understanding for these different relocation type is like this:
>> compiler generate PIC code with different "level of indirection to all global
>> data and function references in the code." And these different level of
>> indirection is implemented through GOT and PLT structure with different
>> addressing calculation pattern. The different calculation patterns are the
>> different relocation types which are defined  by  x86_64 ABI Table 4.9. We
>> don't need worry about how compiler correctly generate code to work with
>> these relocation types, we just need correctly understand their addressing
>> calculation pattern.
>> >
>> > The GOTPCRELX/REX_GOTPCRELX has the same calculation definition in
>> x86_64 ABI Table 4.9 as "G + GOT + A - P". So, I assume their difference is 
>> not
>> in the relocation calculation pattern, but how to co-work with specific
>> instructions to finish these calculation in a hardware optimized way.
>> >
>>
>> No, that is not what these are for. The special types mark
>> instructions that can be converted by the linker into simpler
>> sequences if the symbol turns out to be in the same module. From the
>> doc:
>>
>> mov foo@GOTPCREL(%rip), %reg
>>
>> could be converted by the linker into
>>
>> lea foo(%rip), %reg
>>
>> if the reference to 'foo' is satisfied by a non-preemptible local
>> definition. This is a useful optimization, since it eliminates a
>> memory load. The problem is that we cannot recalculate such
>> relocations in GenFw without checking whether the linker has applied
>> this optimization or not.
>>
> [Steven]: Do you mean the linker will apply above optimization but not remove 
> the original GOTPCREL item? It sounds like a severe linker bug.
>

I checked quickly, and it appears the linker does the right thing
here, i.e., it performs the optimization and also modifies the
relocation emitted into the .rela.text section

So this:

.globl bar
.type bar, @function
bar:
mov foo@GOTPCREL(%rip), %eax
ret

.globl foo
foo:
.quad 0

compiles into

/tmp/pie.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 6 
2: R_X86_64_GOTPCRELX foo-0x4
   6: c3   retq

0007 :
...

but after linking (ld -o /tmp/pie -e bar -q /tmp/pie.o)

/tmp/pie: file format elf64-x86-64


Disassembly of section .text:

004000b0 :
  4000b0: 8d 05 01 00 00 00 lea0x1(%rip),%eax# 4000b7 
4000b2: R_X86_64_PC32 foo-0x4
  4000b6: c3   retq

004000b7 :
...


>>
>> The fact that it works does not make it safe. Having multiple fixups
>> for the same symbol in the .reloc section is a problem, and so is
>> reapplying GOTPCRELX to places where the original instruction has been
>> replaced by the linker.
>>
> [Steven]: I still don't understand why there will be multiple fixups for the 
> same symbol in the .reloc section?
>

Remember this example

>> > int n;
>> > int f () { return n; }
>> > int g () { return n; }
>> > int h () { return n; }

If every 'return n' results in a GOTPCREL relocation, how are you
going to make sure that the GOT entry for 'n' is only fixed up a
single time?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] MdePkg: move to 'hidden' visibility for all symbols under GCC/X64

2016-08-01 Thread Ard Biesheuvel
When using GCC to build for X64, we switched to the position independent
small code model, which is much more efficient in terms of code generation
and runtime relocation footprint, and produces binaries that can execute
correctly from any offset.

However, the PIC routines are by default geared towards hosted binaries
containing symbol references that may resolve to definitions in other
dynamic objects, and for this reason, external symbol references are
indirected via a GOT entry by default (which also results in a .reloc fixup
entry) unless we annotate them.

For this reason, we introduced the 'protected' visibility annotation for
all symbol definitions and references, by setting the GCC visibility
pragma. However, as it turns out, this is not sufficient for all versions
of GCC, and in some cases (GCC 5.x using the GCC49 toolchain tag), may
still result in GOT based relocations.

So switch to 'hidden' visibility instead, which is slightly stronger, and
fixes this issue for the versions of GCC that exhibit the problem.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdePkg/Include/X64/ProcessorBind.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/X64/ProcessorBind.h 
b/MdePkg/Include/X64/ProcessorBind.h
index a4aad3e524e8..666cc8e8bd16 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -29,12 +29,12 @@
 
 #if defined(__GNUC__) && defined(__pic__)
 //
-// Mark all symbol declarations and references as protected, meaning they will
+// Mark all symbol declarations and references as hidden, meaning they will
 // not be subject to symbol preemption. This allows the compiler to refer to
 // symbols directly using relative references rather than via the GOT, which
 // contains absolute symbol addresses that are subject to runtime relocation.
 //
-#pragma GCC visibility push (protected)
+#pragma GCC visibility push (hidden)
 #endif
 
 #if defined(__INTEL_COMPILER)
-- 
2.7.4

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


[edk2] [PATCH v5 4/8] BaseTools GCC: use 'gcc' as the linker command for GCC44 and later

2016-08-01 Thread Ard Biesheuvel
To accommodate upcoming GCCx toolchain versions that require 'gcc' to
be used as the linker in order to support LTO, switch GCC44 and later
(including CLANG35) to a new DLINK build rule that invokes 'gcc' as the
linker instead of 'ld'. Since gcc expects its command line arguments in
a different format, and expects arguments that it needs to pass to the
linker to be prefixed with '-Wl,', this involves changes to most of the
DLINK_FLAGS definitions in tools_def.template, as well as some changes to
module .INF files that set their own linker options.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |   2 +-
 BaseTools/Conf/build_rule.template  |  11 +-
 BaseTools/Conf/tools_def.template   | 170 ++--
 EmulatorPkg/Unix/Host/Host.inf  |   6 +-
 4 files changed, 97 insertions(+), 92 deletions(-)

diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
index a4ea5a05b652..5e706934f69f 100755
--- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
+++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
@@ -107,4 +107,4 @@ [Pcd]
   gArmTokenSpaceGuid.PcdFvBaseAddress
 
 [BuildOptions]
-  GCC:*_*_*_DLINK_FLAGS = -pie -T $(MODULE_DIR)/Scripts/PrePi-PIE.lds
+  GCC:*_*_*_DLINK_FLAGS = -pie -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 3fea4f456118..eb4ae749fda5 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -291,7 +291,11 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST)
 
-<Command.GCC, Command.GCCLD>
+
+"$(DLINK)" -o ${dst} $(DLINK_FLAGS) 
-Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)
+"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
+
+
 "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
@@ -319,7 +323,10 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
-<Command.GCC, Command.GCCLD>
+
+"$(DLINK)" $(DLINK_FLAGS) 
-Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)
+
+
 "$(DLINK)" $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 
 
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8a04e38e1288..10ac21e42c8f 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4329,14 +4329,14 @@ DEFINE GCC_ARM_CC_FLAGS= 
DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi
 DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
-DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
+DEFINE GCC_DLINK2_FLAGS_COMMON = 
-Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 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_AARCH64_DLINK_COMMON= -Wl,--emit-relocs -nostdlib 
-Wl,--gc-sections -u $(IMAGE_ENTRY_POINT) 
-Wl,-e,$(IMAGE_ENTRY_POINT),-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z 
common-page-size=0x20
 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_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_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_DLINK_FLAGS) 
-Wl,--entry,ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
+DEFINE GCC_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) 
-Wl,--entry,ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT)
 DEFINE GCC_IA32_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry 
_

[edk2] [PATCH v5 6/8] BaseTools GCC: drop GNU notes section from EFI image

2016-08-01 Thread Ard Biesheuvel
Recent versions of GNU ld automatically emit a .notes section into
the ELF binary containing a build id. Since this is an allocatable
section by default, it will be identified by GenFw as a section
that requires PE/COFF conversion, which may cause sections to be
moved around unexpectedly.

So retain the section, but tag it as INFO, which tells the linker
that it should not be accounted for in the binary's memory layout.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 BaseTools/Scripts/GccBase.lds | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 7e4cdde9bfea..281af8a9bd33 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -62,6 +62,12 @@ SECTIONS {
 KEEP (*(.hii))
   }
 
+  /*
+   * Retain the GNU build id but in a non-allocatable section so GenFw
+   * does not copy it into the PE/COFF image.
+   */
+  .build-id (INFO) : { *(.note.gnu.build-id) }
+
   /DISCARD/ : {
 *(.note.GNU-stack)
 *(.gnu_debuglink)
-- 
2.7.4

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


[edk2] [PATCH v5 5/8] ArmPkg: add prebuilt glue binaries for GCC5 LTO support

2016-08-01 Thread Ard Biesheuvel
GCC in LTO mode interoperates poorly with non-standard libraries that
provide implementations of compiler intrinsics such as memcpy/memset
or the stack protector entry points. Such libraries need to be built
in non-LTO mode, and then referenced explicitly on the linker command
line using a -plugin-opt=-pass-through=-lxxx linker option.

However, if these intrinsics are also referenced directly, the LTO
version of the code will be pulled in, and will happily satisfy all
other references to the same symbol.

So add a pair of glue libraries, for ARM and AARCH64, that reference
the known intrinsics. Since the binaries live under ArmPkg directly,
we can reference them in tools_def.txt. Under LD garbage collection,
the object itself will be pruned, and so will the intrinsics that end
up unused by the module.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 ArmPkg/Library/GccLto/liblto-aarch64.a | Bin 0 -> 1016 bytes
 ArmPkg/Library/GccLto/liblto-aarch64.s |  27 +
 ArmPkg/Library/GccLto/liblto-arm.a | Bin 0 -> 2096 bytes
 ArmPkg/Library/GccLto/liblto-arm.s |  61 
 4 files changed, 88 insertions(+)

diff --git a/ArmPkg/Library/GccLto/liblto-aarch64.a 
b/ArmPkg/Library/GccLto/liblto-aarch64.a
new file mode 100644
index 
..2ab00238f0dad882abf08a1fb9623c9cdea9f17b
GIT binary patch
literal 1016
zcmbu7!M8btcV>pmaJb3R#Pab@Ovb0qUG$GwJk&}<*)yMErJh~su
zhGA(FBh#ci^V@G{X8(NLKR`dGgNxR5Xq8|a14Nj;_ot@whUR;}*D0W|+#ne8)
z+crcqtbp?TKuy$d;Fk^js)5sWPGwPMt2G8wSV~i4b+$;e`67MRugg8~@}{d?w$pJf
z%hU2Z13wYMF8ko8f}aWQH5;VNy0m%Ghc<?O^ORa42Zb{|ZYEm;}M9QPwkz0*h
zki8>ef}gYSE})e*bOFvFk<j^57EYNXKak(^fcXvc@Z~)5d^m*lCr*Hz|6PAkvlcbK
oxX>*EVPSp5Eivz1-~TrQyaBwMaQ{8W!rrlD%!Td{2n*}~0;u;a`v3p{

literal 0
HcmV?d1

diff --git a/ArmPkg/Library/GccLto/liblto-aarch64.s 
b/ArmPkg/Library/GccLto/liblto-aarch64.s
new file mode 100644
index ..45000d327758
--- /dev/null
+++ b/ArmPkg/Library/GccLto/liblto-aarch64.s
@@ -0,0 +1,27 @@
+//
+// Copyright (c) 2016, Linaro Ltd. All rights reserved.
+//
+// This program and the accompanying materials are licensed and made available 
under
+// the terms and conditions of the BSD License that accompanies this 
distribution.
+// The full text of the license may be found at
+// http://opensource.org/licenses/bsd-license.php.
+//
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+
+//
+// GCC in LTO mode interoperates poorly with non-standard libraries that
+// provide implementations of compiler intrinsics such as memcpy/memset
+// or the stack protector entry points.
+//
+// By referencing these functions from a non-LTO object that can be passed
+// to the linker via the -plugin-opt=-pass-through=-lxxx options, the
+// intrinsics are included in the link in a way that allows them to be
+// pruned again if no other references to them exist.
+//
+
+   .long   memcpy - .
+   .long   memset - .
+   .long   __stack_chk_fail - .
+   .long   __stack_chk_guard - .
diff --git a/ArmPkg/Library/GccLto/liblto-arm.a 
b/ArmPkg/Library/GccLto/liblto-arm.a
new file mode 100644
index 
..d811c09573a35ea87a8002ecf01be18e1c6e7fd3
GIT binary patch
literal 2096
zcmd6o%WKq76vn?XQ*C|Js#WW|YOD1@u(oJH7cHm=wjd(Xg%C3{sS}#eGD-SEunQLz
zT?o1mx)E36>ti;!4n^e}Mi6u3h<^n@J{fT<Fp}Ouq9w_nvbfNlqSKoxD~mm5{X(
zhR`D5^G4ItF=}K8T}U0-`2R^Kc5yYX=T>}_x@dNmx{6!*W2si#P63O*VzW?IBihqh
z=)ig*pojKb#bw326`xc*toV}R>x!op%I;^}JZ=gW^w$zbO8u_=n=3
zihn6C7jA)^cemm`#e<4%#TOM%D88Zij$&7Fpm;^`6UFO_-zdgF4UQAVZgtkF)@Pj=
z*ALnp_Y=1vL)@s|sQDwQ6*Mh*7aYIlFNiybaLxo6PTG16rQHlllhBAv-k>#u2@Sol
zI=`G}CPrQiN;tRR(ak(*AdNItn6xb{AamTrttlr6972!~lYGJ?`uh4`8leFjDu
zR1H=l|GXG+(@3h}e9gF`ML(|A$Jm)#Ny{9*kb6fYIz6K#U~GZXiE;<`AQQJZh#Ex*
zvPafpsg(EM+QeEU%F9+!7AJXjt<6BM=oX+)l${4fw*md4-N1n8cCac_8FW^32XIbw
zCm?m%V%-}PWwOhnEHdMwdw?sVdjY8%7AKh$-3Qzh-4EOrJpf1@u{il%(L=yJ(ZfJZ
z^axNF?FRzUqrklAF(4K_4lIdsu@6KCfmP8Hz#~x>xiwL4;;HB<;F;)Y;DzWJUhHT&
zjNJ+~ZlqeztcDlZv9}b%uDP)byAnmP`PA5M95?(*5_=I7{9EHzOij<eVx#1jh0yHv
z<B{-Nm!6|^Pj~Rl*~wdJ;>*-d{<&4d*_Y!hx!AINvPBvHw{hmarpIg2NWNZUrI#!p
wAAvlV^sI41<6<;hHcoUy=A?e-|05l;7C8giM-Tt9*KBPx@rv+1OG3`f-+dwCzyJUM

literal 0
HcmV?d1

diff --git a/ArmPkg/Library/GccLto/liblto-arm.s 
b/ArmPkg/Library/GccLto/liblto-arm.s
new file mode 100644
index ..bc16320a46c0
--- /dev/null
+++ b/ArmPkg/Library/GccLto/liblto-arm.s
@@ -0,0 +1,61 @@
+//
+// Copyright (c) 2016, Linaro Ltd. All rights reserved.
+//
+// This program and the accompanying materials are licensed and made available 
under
+// the terms and conditions of the BSD License that accompanies this 
distribution.
+// The full text of the lic

[edk2] [PATCH v5 8/8] BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO mode

2016-08-01 Thread Ard Biesheuvel
This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and
AARCH64. Due to the fact that the GCC project switched to a new
numbering scheme where the first digit is now incremented for every
major release, the new toolchain is simply called 'GCC5', and is
intended to support all GCC v5.x releases.

Since IA32 and X64 enable compiler optimizations (-Os) for both DEBUG
and RELEASE builds, LTO support is equally enabled for both targets.
On ARM and AARCH64, DEBUG builds are not optimized, and so the LTO
optimizations are only enabled for RELEASE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 BaseTools/Conf/tools_def.template | 164 
 1 file changed, 164 insertions(+)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 10ac21e42c8f..314adaf6bfa8 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -197,6 +197,9 @@ DEFINE GCC48_X64_PREFIX= ENV(GCC48_BIN)
 DEFINE GCC49_IA32_PREFIX   = ENV(GCC49_BIN)
 DEFINE GCC49_X64_PREFIX= ENV(GCC49_BIN)
 
+DEFINE GCC5_IA32_PREFIX= ENV(GCC5_BIN)
+DEFINE GCC5_X64_PREFIX = ENV(GCC5_BIN)
+
 DEFINE UNIX_IASL_BIN   = ENV(IASL_PREFIX)iasl
 DEFINE WIN_ASL_BIN_DIR = C:\ASL
 DEFINE WIN_IASL_BIN= DEF(WIN_ASL_BIN_DIR)\iasl.exe
@@ -366,6 +369,12 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
Files/CodeSourcery/Sourcery G
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
+#   GCC5-Linux,Windows-  Requires:
+# GCC 5 with LTO support, targeting 
x86_64-linux-gnu, aarch64-linux-gnu, or arm-linux-gnueabi
+#Optional:
+# Required to build platforms or ACPI tables:
+#   Intel(r) ACPI Compiler from
+#   https://acpica.org/downloads
 #   CLANG35 -Linux,Windows-  Requires:
 # Clang v3.5 or later, and GNU binutils targeting 
aarch64-linux-gnu or arm-linux-gnueabi
 #Optional:
@@ -4452,6 +4461,27 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS= 
DEF(GCC48_AARCH64_DLINK2_FLAGS)
 DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
 DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 
+DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -flto 
-fno-builtin
+DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto 
-fno-builtin
+DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
+DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
+DEFINE GCC5_IA32_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto
+DEFINE GCC5_IA32_DLINK2_FLAGS= DEF(GCC49_IA32_DLINK2_FLAGS)
+DEFINE GCC5_X64_DLINK_FLAGS  = DEF(GCC49_X64_DLINK_FLAGS) -flto
+DEFINE GCC5_X64_DLINK2_FLAGS = DEF(GCC49_X64_DLINK2_FLAGS)
+DEFINE GCC5_ASM_FLAGS= DEF(GCC49_ASM_FLAGS)
+DEFINE GCC5_ARM_ASM_FLAGS= DEF(GCC49_ARM_ASM_FLAGS)
+DEFINE GCC5_AARCH64_ASM_FLAGS= DEF(GCC49_AARCH64_ASM_FLAGS)
+DEFINE GCC5_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS)
+DEFINE GCC5_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS)
+DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
+DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -flto
+DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS)
+DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) -flto
+DEFINE GCC5_AARCH64_DLINK2_FLAGS = DEF(GCC49_AARCH64_DLINK2_FLAGS)
+DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS)
+DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
+
 

 #
 # Unix GCC And Intel Linux ACPI Compiler
@@ -5186,6 +5216,140 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
DEF(GCC49_AARCH64_DLINK_FLAGS)
 
 

 #
+# GCC 5 - This configuration is used to compile under Linux to produce
+# PE/COFF binaries using GCC 5
+#
+
+*_GCC5_*_*_FAMILY= GCC
+
+*_GCC5_*_MAKE_PATH   = DEF(GCC5_IA32_PREFIX)make
+*_GCC5_*_*_DLL   = ENV(GCC5_DLL)
+*_GCC5_*_ASL_PATH= DEF(UNIX_IASL_BIN)
+
+*_GCC5_*_PP_FLAGS= DEF(GCC_PP_FLAGS)
+*_GCC5_*_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS)
+*_GCC5_*_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS)
+*_GCC5_*_VFRPP_FLAGS = DEF(GCC

[edk2] [PATCH v5 3/8] BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLD

2016-08-01 Thread Ard Biesheuvel
Before we can make non-backward compatible changes to the GCC build rules
regarding the use of the 'gcc' binary as the linker, clone the existing
GCC build rules into a 'GCCLD' build rule family, and move the legacy
toolchains UNIXGCC, CYGGCC, CYGGCCxASL and ELFGCC over to it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 BaseTools/Conf/build_rule.template | 28 ++--
 BaseTools/Conf/tools_def.template  |  4 +++
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 91bcc1828cb5..3fea4f456118 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -130,7 +130,7 @@
 <Command.MSFT, Command.INTEL>
 "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-<Command.GCC, Command.RVCT>
+<Command.GCC, Command.GCCLD, Command.RVCT>
 # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
 "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
 
@@ -156,7 +156,7 @@
 <Command.MSFT, Command.INTEL>
 "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-<Command.GCC, Command.RVCT>
+<Command.GCC, Command.GCCLD, Command.RVCT>
 # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
 "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
 "$(SYMRENAME)" $(SYMRENAME_FLAGS) ${dst}
@@ -171,7 +171,7 @@
 
 $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 
-
+<Command.GCC, Command.GCCLD>
 "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -o ${dst} $(INC) ${src}
 
 [C-Header-File]
@@ -187,7 +187,7 @@
 <InputFile.MSFT, InputFile.INTEL, InputFile.RVCT>
 ?.asm, ?.Asm, ?.ASM
 
-
+<InputFile.GCC, InputFile.GCCLD>
 ?.S, ?.s
 
 
@@ -201,7 +201,7 @@
 Trim --source-code --convert-hex --trim-long -o 
${d_path}(+)${s_base}.iii ${d_path}(+)${s_base}.i
 "$(ASM)" /Fo${dst} $(ASM_FLAGS) /I${s_path} $(INC) 
${d_path}(+)${s_base}.iii
 
-<Command.GCC, Command.RVCT>
+<Command.GCC, Command.GCCLD, Command.RVCT>
 "$(PP)" $(PP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i
 Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii 
${d_path}(+)${s_base}.i
 # For RVCTCYGWIN ASM_FLAGS must be first to work around pathing issues
@@ -265,7 +265,7 @@
 <Command.MSFT, Command.INTEL>
 "$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)
 
-
+<Command.GCC, Command.GCCLD>
 "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
 
 
@@ -291,7 +291,7 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST)
 
-
+<Command.GCC, Command.GCCLD>
 "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
@@ -319,7 +319,7 @@
 <Command.MSFT, Command.INTEL>
 "$(DLINK)" $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
-
+<Command.GCC, Command.GCCLD>
 "$(DLINK)" $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
 
 
@@ -346,7 +346,7 @@
 $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
 -$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 -$(CP) $(DEBUG_DIR)(+)*.pdb $(OUTPUT_DIR) 
-
+<Command.GCC, Command.GCCLD>
 $(CP) ${src} $(DEBUG_DIR)(+)$(MODULE_NAME).debug
 $(OBJCOPY) --strip-unneeded -R .eh_frame ${src}
 
@@ -402,7 +402,7 @@
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
 
-
+<Command.GCC, Command.GCCLD>
 Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i 
$(INC_LIST) ${src}
 "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
@@ -423,7 +423,7 @@
 "$(ASLDLINK)" /OUT:$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
 
-
+<Command.GCC, Command.GCCLD>
 "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_di

[edk2] [PATCH v5 2/8] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note sections

2016-08-01 Thread Ard Biesheuvel
Newer versions of ld automatically emit .gnu.hash and .note.gnu.build-id
sections, which are not listed in the linker script, and will end up
breaking the build with an allocation conflict, e.g.,

  /usr/bin/aarch64-linux-gnu-ld: section .note.gnu.build-id loaded at
[,0023] overlaps section .text loaded at
[,00017dbf]

Since we don't require or care about these sections, update the linker
script so that they are discarded. Note that this involves emitting the
.note.gnu.build-id section into a non-allocatable segment to prevent the
linker from noticing that it is being discarded (and subsequently
complaining about it)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Laszlo Ersek <ler...@redhat.com>
Acked-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds 
b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
index 832ad1474468..44df7840adfd 100644
--- a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
+++ b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
@@ -30,8 +30,11 @@ SECTIONS
 PROVIDE(__reloc_end = .);
   }
 
+  .note (INFO) : { *(.note.gnu.build-id) }
+
   /DISCARD/ : {
 *(.note.GNU-stack)
+*(.gnu.hash)
 *(.gnu_debuglink)
 *(.interp)
 *(.dynamic)
-- 
2.7.4

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


[edk2] [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

2016-08-01 Thread Ard Biesheuvel
This v5 to introduce GCC5 is now a 8 piece series, including some
preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
to switch to using 'gcc' as the linker. This allows us to get rid of
the wrapper script to marshall ld arguments in order to make them
understandable by gcc, which is fragile and likely to cause problems in
the future.

Since there appears to be a natural split between the 'legacy' GCC
toolchains UNIXGCC, ELFGCC, and CYGGCC[xASL], both in term of supported
architectures [IA32, X64, IPF] vs [IA32, X64, ARM, AARCH64], and in
terms of maintenance, these toolchains are not moved to using 'gcc' as
the linker, and instead, a new BUILDRULEFAMILY is introduced called GCCLD
that will retain the old behavior.

The result is that GCC5 can align much more closely with its predecessors,
making the expected maintenance burden of supporting GCC back to v4.4
much lower.

Changes since v4:
- added patch to use 'protected' visibility only for the libraries that
  define the module entry points (_ModuleEntryPoint), to prevent them from
  being optimized away by the LTO routines
- added Jordan's ack/RBs
- add some extra comments to tools_def.template (#8)

Changes since v3:
- like Steven does in his GCC5LTO patch, add -fno-builtin to IA32 and X64
  CC_FLAGS; this addresses a build issue reported by Liming
- add -Os the the linker flags as well, for AARCH64 this does not seem to make
  a difference, but it is arguably correct since the LTO processing at link
  time involves code generation as well
- add Laszlo's ack to #2
- new patch #6 to omit the autogenerated build-id from the PE/COFF binary

Changes since v2:
- add license headers to LTO glue files for ARM and AARCH64 (#5)
- get rid of lto-ld-wrapper script

Ard Biesheuvel (8):
  BaseTools CLANG35: drop problematic use-movt and save-temps options
  ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note
sections
  BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into
GCCLD
  BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
  ArmPkg: add prebuilt glue binaries for GCC5 LTO support
  BaseTools GCC: drop GNU notes section from EFI image
  MdePkg GCC/X64: avoid 'hidden' visibility for module entry points
  BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO
mode

 ArmPkg/GccLto/liblto-aarch64.a | Bin 0 
-> 1016 bytes
 ArmPkg/GccLto/liblto-aarch64.s |  27 ++
 ArmPkg/GccLto/liblto-arm.a | Bin 0 
-> 2096 bytes
 ArmPkg/GccLto/liblto-arm.s |  61 

 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf|   2 +-
 ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds |   3 +
 BaseTools/Conf/build_rule.template |  31 +-
 BaseTools/Conf/tools_def.template  | 350 
+++-
 BaseTools/Scripts/GccBase.lds  |   6 +
 EmulatorPkg/Unix/Host/Host.inf |   6 +-
 MdePkg/Include/X64/ProcessorBind.h |   9 +-
 MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf |   2 +
 MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf |   2 +
 MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf   |   2 +
 MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf |   2 +
 MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf   |   2 +
 16 files changed, 396 insertions(+), 109 deletions(-)
 create mode 100644 ArmPkg/GccLto/liblto-aarch64.a
 create mode 100644 ArmPkg/GccLto/liblto-aarch64.s
 create mode 100644 ArmPkg/GccLto/liblto-arm.a
 create mode 100644 ArmPkg/GccLto/liblto-arm.s

-- 
2.7.4

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


[edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

2016-08-01 Thread Ard Biesheuvel
When building with LTO enabled, the LTO routines infer from the 'hidden'
visibility of the _ModuleEntryPoint symbol that its code only needs to be
retained if it is referenced internally, and disregards the fact that
it is referenced by the entry point field in the ELF metadata.

This is arguably a bug in LTO, but we can work around it by ensuring that
the _ModuleEntryPoint symbol is emitted with protected visibility instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdePkg/Include/X64/ProcessorBind.h | 9 
-
 MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf | 2 ++
 MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf | 2 ++
 MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf   | 2 ++
 MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf | 2 ++
 MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf   | 2 ++
 6 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/X64/ProcessorBind.h 
b/MdePkg/Include/X64/ProcessorBind.h
index 666cc8e8bd16..e45b9cba2bb3 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -29,13 +29,20 @@
 
 #if defined(__GNUC__) && defined(__pic__)
 //
-// Mark all symbol declarations and references as hidden, meaning they will
+// Mark all symbol declarations and references as hidden*, meaning they will
 // not be subject to symbol preemption. This allows the compiler to refer to
 // symbols directly using relative references rather than via the GOT, which
 // contains absolute symbol addresses that are subject to runtime relocation.
 //
+// * Under LTO, the entry point of a module must have protected or default
+//   visibility to prevent it from being pruned.
+//
+#ifdef GCC_VISIBILITY_PROTECTED
+#pragma GCC visibility push (protected)
+#else
 #pragma GCC visibility push (hidden)
 #endif
+#endif
 
 #if defined(__INTEL_COMPILER)
 //
diff --git a/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf 
b/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
index 01f64c34c7a1..2d6f87ed062e 100644
--- a/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
+++ b/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
@@ -39,3 +39,5 @@ [LibraryClasses]
   BaseLib
   DebugLib
 
+[BuildOptions]
+  GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
diff --git a/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf 
b/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
index d920306713c5..4e61783b3bd5 100644
--- a/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
+++ b/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
@@ -37,3 +37,5 @@ [LibraryClasses]
   BaseLib
   DebugLib
 
+[BuildOptions]
+  GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
diff --git a/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf 
b/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
index a2db9e058bbe..adfd91bdc57e 100644
--- a/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
+++ b/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
@@ -37,3 +37,5 @@ [Packages]
 [LibraryClasses]
   DebugLib
 
+[BuildOptions]
+  GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
diff --git 
a/MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf 
b/MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
index be92b3dc0760..9525c55c2051 100644
--- a/MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
+++ b/MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
@@ -38,3 +38,5 @@ [LibraryClasses]
   DebugLib
   BaseLib
 
+[BuildOptions]
+  GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
diff --git a/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf 
b/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
index 7a9dcbcd4df2..8d30b1197850 100644
--- a/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+++ b/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
@@ -65,3 +65,5 @@ [Depex.common.UEFI_DRIVER]
   gEfiVariableArchProtocolGuid AND
   gEfiWatchdogTimerArchProtocolGuid
 
+[BuildOptions]
+  GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
-- 
2.7.4

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


Re: [edk2] [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 04:26, Gao, Liming  wrote:
> Ard:
>  My GNU ld (GNU Binutils for Ubuntu) 2.24. Which version you use?
>
> 1. #pragma GCC visibility push (hidden) , GCC5 with GCC49 tool chain pass. 
> GCC5 with GCC5 tool chain failure. Here is failure message.
> GenFw: Elf64Convert.c:424: ScanSections64: Assertion `((BOOLEAN)(0==1))' 
> failed.
> GenFw: ERROR 3000: Invalid
>   Did not find any '.text' section.
> Aborted (core dumped)
>
> 2. #pragma GCC visibility push (protected), GCC5 with GCC49 tool chain 
> failure, GCC5 with GCC5 tool chain pass. Failure message is below.
>

Thanks for checking. The problem with GCC5 is that the fact that
'_ModuleEntryPoint' is also hidden, which confuses the LTO code and
makes it eliminate all input objects. I think this is a bug in LTO,
since the entry point is passed explicitly to the linker using the -e
option. But we still need to work around it.

Since the current issue (#2) is a problem with GCC49, I will propose a
separate patch to fix it by changing the 'protected' to 'hidden'. I
will then add a patch to my GCC5 series as well to work around the LTO
problem.

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


[edk2] [PATCH v5 1/8] BaseTools CLANG35: drop problematic use-movt and save-temps options

2016-08-01 Thread Ard Biesheuvel
Some versions of Clang fail on every input file when using the
-save-temps options, and produces the following heplful error message:

  :0: error: Undefined temporary symbol

Simply dropping the option for CLANG35 is the simplest way around this,
since the value of storing .i and .s files is dubious anyway.

Also, drop the arm-use-movt option, which does not appear to be
supported anymore by recent versions of clang.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 BaseTools/Conf/tools_def.template | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 847b9f729f29..b36a19314215 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4325,8 +4325,8 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
-fno-strict-aliasing -
 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) -mlittle-endian 
-mabi=aapcs -fno-short-enums -save-temps -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
-DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -save-temps -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
+DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
+DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
@@ -4384,7 +4384,7 @@ 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 
-mword-relocations
+DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector 
-mword-relocations -save-temps
 DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) 
--oformat=elf32-littlearm
 DEFINE GCC46_ARM_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
--defsym=PECOFF_HEADER_SIZE=0x220
 DEFINE GCC46_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_ASLDLINK_FLAGS) 
--oformat=elf32-littlearm
@@ -4401,7 +4401,7 @@ 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(GCC44_ALL_CC_FLAGS) -mcmodel=large DEF(GCC_AARCH64_CC_FLAGS)
+DEFINE GCC47_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) -mcmodel=large DEF(GCC_AARCH64_CC_FLAGS) -save-temps
 DEFINE GCC47_AARCH64_CC_XIPFLAGS = DEF(GCC_AARCH64_CC_XIPFLAGS)
 DEFINE GCC47_ARM_DLINK_FLAGS = DEF(GCC46_ARM_DLINK_FLAGS)
 DEFINE GCC47_ARM_DLINK2_FLAGS= DEF(GCC46_ARM_DLINK2_FLAGS)
@@ -4443,7 +4443,7 @@ 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= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_AARCH64_CC_FLAGS)
+DEFINE GCC49_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_AARCH64_CC_FLAGS) -save-temps
 DEFINE GCC49_AARCH64_CC_XIPFLAGS = DEF(GCC48_AARCH64_CC_XIPFLAGS)
 DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FL

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 09:54, Shi, Steven  wrote:
>> On 1 August 2016 at 09:19, Shi, Steven 
>> > wrote:
>> >> >>
>> >> >> The fact that it works does not make it safe. Having multiple fixups
>> >> >> for the same symbol in the .reloc section is a problem, and so is
>> >> >> reapplying GOTPCRELX to places where the original instruction has
>> been
>> >> >> replaced by the linker.
>> >> >>
>> >> > [Steven]: I still don't understand why there will be multiple fixups 
>> >> > for the
>> >> same symbol in the .reloc section?
>> >> >
>> >>
>> >> Remember this example
>> >>
>> >> >> > int n;
>> >> >> > int f () { return n; }
>> >> >> > int g () { return n; }
>> >> >> > int h () { return n; }
>> >>
>> >> If every 'return n' results in a GOTPCREL relocation, how are you
>> >> going to make sure that the GOT entry for 'n' is only fixed up a
>> >> single time?
>> >
>> > [Steven]: the 'return n' will not result in relocation, but the 'int n' 
>> > will result
>> in the relocation in GOT. The three 'return n' will point to the same 'int n'
>> relocation item. So, we need only fixup 'int n' once, all three 'return n' 
>> will
>> use the correct global 'n' value.
>>
>> Every 'return n' will result in a GOTPCREL relocation against n. And
>> your code emits a relocation for the GOT entry every time.
>>
> [Steven]: I don't think so. please give a real case and offer its source code 
> to prove " Every 'return n' will result in a GOTPCREL relocation against n ".
>

Compiling the code above using

gcc -c -O -fpic /tmp/pie.c -o pie.o

and dumping it using

readelf -r pie.o

gives me

Relocation section '.rela.text' at offset 0x250 contains 3 entries:
  Offset  Info   Type   Sym. ValueSym. Name + Addend
0003  000a002a R_X86_64_REX_GOTP 0004 n - 4
000d  000a002a R_X86_64_REX_GOTP 0004 n - 4
0017  000a002a R_X86_64_REX_GOTP 0004 n - 4
...

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


Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 09:19, Shi, Steven  wrote:
>> >>
>> >> The fact that it works does not make it safe. Having multiple fixups
>> >> for the same symbol in the .reloc section is a problem, and so is
>> >> reapplying GOTPCRELX to places where the original instruction has been
>> >> replaced by the linker.
>> >>
>> > [Steven]: I still don't understand why there will be multiple fixups for 
>> > the
>> same symbol in the .reloc section?
>> >
>>
>> Remember this example
>>
>> >> > int n;
>> >> > int f () { return n; }
>> >> > int g () { return n; }
>> >> > int h () { return n; }
>>
>> If every 'return n' results in a GOTPCREL relocation, how are you
>> going to make sure that the GOT entry for 'n' is only fixed up a
>> single time?
>
> [Steven]: the 'return n' will not result in relocation, but the 'int n' will 
> result in the relocation in GOT. The three 'return n' will point to the same 
> 'int n' relocation item. So, we need only fixup 'int n' once, all three 
> 'return n' will use the correct global 'n' value.

Every 'return n' will result in a GOTPCREL relocation against n. And
your code emits a relocation for the GOT entry every time.

 BTW, the 'int n' relocation type in your code on X64 should be
R_X86_64_GLOB_DAT
>

R_X86_64_GLOB_DAT is a dynamic relocation type. These are only emitted
when linking a shared object or a PIE executable, which I would like
to avoid as well.

The problem with PIE executables is that the .rela.xxx sections
emitted for each section, and the single .rela section containing the
dynamic relocations overlap with each other, i.e., places containing
absolute symbol addresses in the binary will appear in both, and
emitting reloc fixups for all relocations will result in duplicates.

> You can see the 'int myglob' in Eli's example in 
> http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/.
>  The 'int myglob' is same as your 'int n' example.
>
> int myglob = 42;
> int ml_func(int a, int b)
> {
> return myglob + a + b;
> }
>

Yes, and every reference to 'myglob' will result in a GOTPCREL
relocation. We must not emit a fixup for myglob every time.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 1/2] BaseTools/GenFw AARCH64: convert ADRP to ADR if binary size allows it

2016-08-01 Thread Ard Biesheuvel
On 27 July 2016 at 13:26, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> The ADRP instruction in the AArch64 ISA requires the link time and load
> time offsets of a binary to be equal modulo 4 KB. The reason is that this
> instruction always produces a multiple of 4 KB, and relies on a subsequent
> ADD or LDR instruction to set the offset into the page. The resulting
> symbol reference only produces the correct value if the symbol in question
> resides at that exact offset into the page, and so loading the binary at
> arbitrary offsets is not possible.
>
> Due to the various levels of padding when packing FVs into FVs into FDs,
> this alignment is very costly for XIP code, and so we would like to relax
> this alignment requirement if possible.
>
> Given that symbols that are sufficiently close (within 1 MB) of the
> reference can also be reached using an ADR instruction which does not
> suffer from this alignment issue, let's replace ADRP instructions with ADR
> after linking if the offset can be encoded in this instruction's immediate
> field. Note that this only makes sense if the section alignment is < 4 KB.
> Otherwise, replacing the ADRP has no benefit, considering that the
> subsequent ADD or LDR instruction is retained, and that micro-architectures
> are more likely to be optimized for ADRP/ADD pairs (i.e., via micro op
> fusing) than for ADR/ADD pairs, which are non-typical.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

@Liming, @Leif:

are there any objections to these patches? I know it is unfortunate
that we need to modify instructions as part of the ELF to PE/COFF
conversion, but it is very effective

ArmVirtQemu-AARCH64 built with CLANG35:

Before:

FVMAIN_COMPACT [41%Full] 2093056 total, 868416 used, 1224640 free
FVMAIN [99%Full] 4848064 total, 4848008 used, 56 free

After:

FVMAIN_COMPACT [36%Full] 2093056 total, 768064 used, 1324992 free
FVMAIN [99%Full] 4848064 total, 4848008 used, 56 free

For comparision, GCC49

FVMAIN_COMPACT [35%Full] 2093056 total, 749960 used, 1343096 free
FVMAIN [99%Full] 3929088 total, 3929032 used, 56 free

and GCC5 (with LTO)

FVMAIN_COMPACT [34%Full] 2093056 total, 732400 used, 1360656 free
FVMAIN [99%Full] 3730240 total, 3730216 used, 24 free

In other words, it turns CLANG35 from a pathetic outlier into
something usable :-)

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


Re: [edk2] [PATCH] ArmPkg/Library: Add ArmReadSctlr for aarch64

2016-08-01 Thread Ard Biesheuvel
On 30 July 2016 at 01:06, Supreeth Venkatesh  wrote:
> One of the UEFI Self Certification tests (UEFI-SCT) need to read the
> current exception level SCTLR Register.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: John Powell 
> Signed-off-by: Supreeth Venkatesh 
> ---

Thanks for the patch. I don't think mentioning the UEFI-SCT here makes
any sense, since the function is defined in ArmLIb.h, and simply
missing from the AARCH64 implementation.

I fixed this up when applying (07783fdd67e4)

Thanks,
Ard.




>  ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
> index a6fd5e3..c9f3bd1 100644
> --- a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
> @@ -1,7 +1,7 @@
>  
> #--
>  #
>  # Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> -# Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
> +# Copyright (c) 2011 - 2016, 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
> @@ -39,6 +39,7 @@ GCC_ASM_EXPORT (ArmCallWFE)
>  GCC_ASM_EXPORT (ArmCallSEV)
>  GCC_ASM_EXPORT (ArmReadCpuActlr)
>  GCC_ASM_EXPORT (ArmWriteCpuActlr)
> +GCC_ASM_EXPORT (ArmReadSctlr)
>
>  
> #--
>
> @@ -205,4 +206,13 @@ ASM_PFX(ArmWriteCpuActlr):
>isb
>ret
>
> +ASM_PFX(ArmReadSctlr):
> +  EL1_OR_EL2_OR_EL3(x1)
> +1:mrs   x0, sctlr_el1
> +  ret
> +2:mrs   x0, sctlr_el2
> +  ret
> +3:mrs   x0, sctlr_el3
> +4:ret
> +
>  ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> --
> 2.8.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

2016-08-01 Thread Ard Biesheuvel
On 29 July 2016 at 23:58, Daniil Egranov  wrote:
> Hi Leif,
>
>
>
> On 07/29/2016 11:06 AM, Leif Lindholm wrote:
>>
>> From: Jeff Brasen 
>>
>> Adds support for the EBC VM for AARCH64 platforms
>>
>> Submitted on behalf of a third-party: The Linux Foundation
>> This contribution is licensed under the BSD license as found at
>> http://opensource.org/licenses/bsd-license.php
>>
>> [Taken from https://source.codeaurora.org/external/server/edk2-blue/]
>> Signed-off-by: Leif Lindholm 
>> ---
>>   .../Universal/EbcDxe/AArch64/EbcLowLevel.S | 135 +
>>   MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c | 563
>> +
>>   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf   |   6 +-
>>   3 files changed, 703 insertions(+), 1 deletion(-)
>>   create mode 100644 MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>>   create mode 100644 MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c
>>
>> diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> new file mode 100644
>> index 000..e858227
>> --- /dev/null
>> +++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> @@ -0,0 +1,135 @@
>> +#/** @file
>> +#
>> +#This code provides low level routines that support the Virtual
>> Machine
>> +#   for option ROMs.
>> +#
>> +#  Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> +#  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
>> +#  This program and the accompanying materials
>> +#  are licensed and made available under the terms and conditions of the
>> BSD License
>> +#  which accompanies this distribution.  The full text of the license may
>> be found at
>> +#  http://opensource.org/licenses/bsd-license.php
>> +#
>> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> IMPLIED.
>> +#
>> +#**/
>> +
>>
>> +#---
>> +# Equate files needed.
>>
>> +#---
>> +
>> +ASM_GLOBAL ASM_PFX(CopyMem);
>> +ASM_GLOBAL ASM_PFX(EbcInterpret);
>> +ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
>> +
>>
>> +#
>> +# EbcLLCALLEX
>> +#
>> +# This function is called to execute an EBC CALLEX instruction.
>> +# This instruction requires that we thunk out to external native
>> +# code. For AArch64, we copy the VM stack into the main stack and then
>> pop
>> +# the first 8 arguments off according to the AArch64 Procedure Call
>> Standard
>> +# On return, we restore the stack pointer to its original location.
>> +#
>>
>> +#
>> +# UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer, VOID
>> *FramePtr)
>
> The code has a mix of using UINTN and UINT64 types. Even the ProcessorBind.h
> defines UINTN as UINT64 for Aarch64, this code is specific for the Aarch64
> architecture. Should the UINT64 type be explicitly used instead of UINTN and
> avoid mixing of this types?
>

I don't object to using UINTN and UINT64 interchangeably in a file
that is specific to an architecture where they resolve to the same
thing.

>> +ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
>> +ASM_PFX(EbcLLCALLEXNative):
>> +  stp  x19, x20, [sp, #-16]!
>> +  stp  x29, x30, [sp, #-16]!
>> +
>> +  mov  x19, x0
>> +  mov  x20, sp
>> +  sub  x2, x2, x1   // Length = NewStackPointer-FramePtr
>> +  sub  sp, sp, x2
>> +  sub  sp, sp, #64  // Make sure there is room for at least 8 args in
>> the new stack
>> +  mov  x0, sp
>> +
>> +  bl   CopyMem  // Sp, NewStackPointer, Length
>> +
>> +  ldp  x0, x1, [sp], #16
>> +  ldp  x2, x3, [sp], #16
>> +  ldp  x4, x5, [sp], #16
>> +  ldp  x6, x7, [sp], #16
>> +
>> +  blr  x19
>> +
>> +  mov  sp,  x20
>> +  ldp  x29, x30, [sp], #16
>> +  ldp  x19, x20, [sp], #16
>> +
>> +  ret
>> +
>>
>> +#
>> +# EbcLLEbcInterpret
>> +#
>> +# This function is called by the thunk code to handle an Native to EBC
>> call
>> +# This can handle up to 16 arguments (1-8 on in x0-x7, 9-16 are on the
>> stack)
>> +# x9 contains the Entry point that will be the first argument when
>> +# EBCInterpret is called.
>> +#
>>
>> +#
>> +ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
>> +ASM_PFX(EbcLLEbcInterpret):
>> +stp  x29, x30, [sp, #-16]!
>> +
>> +// copy the current arguments 9-16 from old location and add arg 7 to
>> stack
>> +// keeping 16 byte stack alignment
>> +sub sp, sp, #80
>> +str x7, [sp]
>> +ldr x11, [sp, #96]
>> +str x11, 

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

2016-08-01 Thread Ard Biesheuvel
(adding back our friends on cc)

On 1 August 2016 at 12:36, Shi, Steven  wrote:
>> On 1 August 2016 at 12:16, Shi, Steven  wrote:
>> >> OK, another example:
>> >>
>> >> pie.s:
>> >>
>> >> .globl foo
>> >> foo:
>> >> pushq n@GOTPCREL(%rip)
>> >> popq%rax
>> >> ret
>> >>
>> >> .globl  bar
>> >> bar:
>> >> pushq   n@GOTPCREL(%rip)
>> >> popq%rax
>> >> ret
>> >>
>> >> .globl n
>> >> n:
>> >> .quad 0
>> >>
>> >> compile and link using
>> >>
>> >> gcc -c -o pie.o /tmp/pie.s
>> >> ld -q -o pie pie.o -e foo
>> >>
>> >> gives me
>> >>
>> >> Relocation section '.rela.text' at offset 0x260 contains 2 entries:
>> >>   Offset  Info   Type   Sym. ValueSym. Name + 
>> >> Addend
>> >> 004000b2  00070009 R_X86_64_GOTPCREL 004000be
>> n -
>> >> 4
>> >> 004000b9  00070009 R_X86_64_GOTPCREL 004000be
>> n -
>> >> 4
>> >>
>> >> Here, pie is a fully linked binary.
>> >>
>> > [Steven]: In this example, there are two R_X86_64_GOTPCREL relocation
>> address in the .text section need to fix up with same symbol runtime address,
>> these two relocation addresses are not same, and every relocation address
>> will be fixed up once. I don't see the problem of "Having multiple fixups for
>> the same symbol in the .reloc section", and  current GenFw code should has
>> no problem on this example.
>> >
>>
>> How many times will your code call CoffAddFixup() for the address of n?
> [Steven]: My understanding is the n address (6000c8) is not a GOTPCREL 
> relocation in .text section, but the 4000b2 and 4000b2 are GOTPCREL 
> relocation in .text section. My CoffAddFixup() will only call twice for 
> 4000b2 and 4000b2, but not for n address (6000c8).
>
> Disassembly of section .text:
>
> 004000b0 :
>   4000b0:   ff 35 12 00 20 00   pushq  0x200012(%rip)# 6000c8 
> 
>   4000b6:   58  pop%rax
>   4000b7:   c3  retq
>
> 004000b8 :
>   4000b8:   ff 35 0a 00 20 00   pushq  0x2a(%rip)# 6000c8 
> 
>   4000be:   58  pop%rax
>   4000bf:   c3  retq
>
> 004000c0 :
> ...
>

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+  CoffAddFixup(
+(UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.

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


Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 16:18, Gao, Liming <liming@intel.com> wrote:
> Ard:
>   I don't think it is good way to define GCC_VISIBILITY_PROTECTED and apply 
> it in EntryPointLib. We only need to expose _ModuleEntryPoint. It has been 
> specified in LINK_FLAGS in tools_def.txt. Could we also specify its attribute 
> in CC_FLAGS or LINK_FLAGS in tools_def.txt?
>

It seems this does the trick as well

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 281af8a9bd33..02387d4f8d6f 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -80,3 +80,7 @@ SECTIONS {
 *(COMMON)
   }
 }
+
+VERSION {
+  { global: _ModuleEntryPoint*; };
+};


Note that * at the end: this is necessary since _ModuleEntryPoint will
be called _ModuleEntryPoint.lto_priv.xxx in the LTO objects.

I will drop this patch, and add this hunk to GccBase.lds instead.

-- 
Ard.


> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Monday, August 01, 2016 4:02 PM
>> To: Shi, Steven ; Zhu, Yonghong
>> ; Gao, Liming ; Justen,
>> Jordan L ; edk2-devel@lists.01.org
>> Cc: ler...@redhat.com; leif.lindh...@linaro.org; Ard Biesheuvel
>>
>> Subject: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for
>> module entry points
>>
>> When building with LTO enabled, the LTO routines infer from the 'hidden'
>> visibility of the _ModuleEntryPoint symbol that its code only needs to be
>> retained if it is referenced internally, and disregards the fact that
>> it is referenced by the entry point field in the ELF metadata.
>>
>> This is arguably a bug in LTO, but we can work around it by ensuring that
>> the _ModuleEntryPoint symbol is emitted with protected visibility instead.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel
>> ---
>> MdePkg/Include/X64/ProcessorBind.h | 9 -
>> MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf | 2 ++
>> MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf | 2 ++
>> MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf | 2 ++
>> MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf | 2
>> ++
>> MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf | 2 ++
>> 6 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdePkg/Include/X64/ProcessorBind.h
>> b/MdePkg/Include/X64/ProcessorBind.h
>> index 666cc8e8bd16..e45b9cba2bb3 100644
>> --- a/MdePkg/Include/X64/ProcessorBind.h
>> +++ b/MdePkg/Include/X64/ProcessorBind.h
>> @@ -29,13 +29,20 @@
>>
>> #if defined(__GNUC__) && defined(__pic__)
>> //
>> -// Mark all symbol declarations and references as hidden, meaning they will
>> +// Mark all symbol declarations and references as hidden*, meaning they
>> will
>> // not be subject to symbol preemption. This allows the compiler to refer to
>> // symbols directly using relative references rather than via the GOT, which
>> // contains absolute symbol addresses that are subject to runtime relocation.
>> //
>> +// * Under LTO, the entry point of a module must have protected or default
>> +// visibility to prevent it from being pruned.
>> +//
>> +#ifdef GCC_VISIBILITY_PROTECTED
>> +#pragma GCC visibility push (protected)
>> +#else
>> #pragma GCC visibility push (hidden)
>> #endif
>> +#endif
>>
>> #if defined(__INTEL_COMPILER)
>> //
>> diff --git a/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>> b/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>> index 01f64c34c7a1..2d6f87ed062e 100644
>> --- a/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>> +++ b/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>> @@ -39,3 +39,5 @@ [LibraryClasses]
>> BaseLib
>> DebugLib
>>
>> +[BuildOptions]
>> + GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
>> diff --git a/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
>> b/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
>> index d920306713c5..4e61783b3bd5 100644
>> --- a/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
>> +++ b/MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
>> @@ -37,3 +37,5 @@ [LibraryClasses]
>> BaseLib
>> DebugLib
>>
>> +[BuildOptions]
>> + GCC:*_*_X64_CC_FLAGS = -DGCC_VISIBILITY_PROTECTED
>> diff --git a/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
>> b/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
>> index a2db9e058bbe..adfd91bdc57e 100644

[edk2] [PATCH 1/2] MdeModulePkg/EbcDxe AARCH64: fix comment style

2016-08-01 Thread Ard Biesheuvel
Replace '#' comments with '//'

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S | 92 ++--
 1 file changed, 44 insertions(+), 48 deletions(-)

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S 
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
index e858227586a8..3c1a461f5e87 100644
--- a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -1,39 +1,35 @@
-#/** @file
-#
-#This code provides low level routines that support the Virtual Machine
-#   for option ROMs.
-#
-#  Copyright (c) 2015, The Linux Foundation. All rights reserved.
-#  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#**/
-
-#---
-# Equate files needed.
-#---
+///** @file
+//
+//This code provides low level routines that support the Virtual Machine
+//   for option ROMs.
+//
+//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
+//  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+//  This program and the accompanying materials
+//  are licensed and made available under the terms and conditions of the BSD 
License
+//  which accompanies this distribution.  The full text of the license may be 
found at
+//  http://opensource.org/licenses/bsd-license.php
+//
+//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+//**/
 
 ASM_GLOBAL ASM_PFX(CopyMem);
 ASM_GLOBAL ASM_PFX(EbcInterpret);
 ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
 
-#
-# EbcLLCALLEX
-#
-# This function is called to execute an EBC CALLEX instruction.
-# This instruction requires that we thunk out to external native
-# code. For AArch64, we copy the VM stack into the main stack and then pop
-# the first 8 arguments off according to the AArch64 Procedure Call Standard
-# On return, we restore the stack pointer to its original location.
-#
-#
-# UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer, VOID 
*FramePtr)
+//
+// EbcLLCALLEX
+//
+// This function is called to execute an EBC CALLEX instruction.
+// This instruction requires that we thunk out to external native
+// code. For AArch64, we copy the VM stack into the main stack and then pop
+// the first 8 arguments off according to the AArch64 Procedure Call Standard
+// On return, we restore the stack pointer to its original location.
+//
+//
+// UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer, VOID 
*FramePtr)
 ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
 ASM_PFX(EbcLLCALLEXNative):
   stp  x19, x20, [sp, #-16]!
@@ -61,15 +57,15 @@ ASM_PFX(EbcLLCALLEXNative):
 
   ret
 
-#
-# EbcLLEbcInterpret
-#
-# This function is called by the thunk code to handle an Native to EBC call
-# This can handle up to 16 arguments (1-8 on in x0-x7, 9-16 are on the stack)
-# x9 contains the Entry point that will be the first argument when
-# EBCInterpret is called.
-#
-#
+//
+// EbcLLEbcInterpret
+//
+// This function is called by the thunk code to handle an Native to EBC call
+// This can handle up to 16 arguments (1-8 on in x0-x7, 9-16 are on the stack)
+// x9 contains the Entry point that will be the first argument when
+// EBCInterpret is called.
+//
+//
 ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
 ASM_PFX(EbcLLEbcInterpret):
 stp  x29, x30, [sp, #-16]!
@@ -113,14 +109,14 @@ ASM_PFX(EbcLLEbcInterpret):
 
 ret
 
-#
-# EbcLLExecuteEbcImageEntryPoint
-#
-# This function is called by the thunk code to handle the image entry point
-# x9 contains the Entry point that 

[edk2] [PATCH 2/2] MdeModulePkg/EbcDxe: cleanup

2016-08-01 Thread Ard Biesheuvel
- indentation
- premature optimization of the thunking code, i.e., align function prototypes
  so we don't have to move arguments around or duplicate them on the stack,
  and perform tail calls where possible
- adhere to calling convention (stack frame layout)
- replace instruction buffer with a fixed struct, so that we no longer have
  to traverse it to find the entry point slots

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S | 188 ++-
 MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c  | 193 ++--
 2 files changed, 159 insertions(+), 222 deletions(-)

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S 
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
index 3c1a461f5e87..d0a5a4c5a37d 100644
--- a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -1,10 +1,12 @@
 ///** @file
 //
-//This code provides low level routines that support the Virtual Machine
-//   for option ROMs.
+//  This code provides low level routines that support the Virtual Machine
+//  for option ROMs.
 //
-//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
+//  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
 //  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+//
 //  This program and the accompanying materials
 //  are licensed and made available under the terms and conditions of the BSD 
License
 //  which accompanies this distribution.  The full text of the license may be 
found at
@@ -15,9 +17,10 @@
 //
 //**/
 
-ASM_GLOBAL ASM_PFX(CopyMem);
-ASM_GLOBAL ASM_PFX(EbcInterpret);
-ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
+ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
+ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
+
+ASM_GLOBAL ASM_PFX(mEbcInstructionBufferTemplate);
 
 //
 // EbcLLCALLEX
@@ -30,102 +33,121 @@ ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
 //
 //
 // UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer, VOID 
*FramePtr)
-ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
 ASM_PFX(EbcLLCALLEXNative):
-  stp  x19, x20, [sp, #-16]!
-  stp  x29, x30, [sp, #-16]!
-
-  mov  x19, x0
-  mov  x20, sp
-  sub  x2, x2, x1   // Length = NewStackPointer-FramePtr
-  sub  sp, sp, x2
-  sub  sp, sp, #64  // Make sure there is room for at least 8 args in the 
new stack
-  mov  x0, sp
-
-  bl   CopyMem  // Sp, NewStackPointer, Length
-
-  ldp  x0, x1, [sp], #16
-  ldp  x2, x3, [sp], #16
-  ldp  x4, x5, [sp], #16
-  ldp  x6, x7, [sp], #16
-
-  blr  x19
-
-  mov  sp,  x20
-  ldp  x29, x30, [sp], #16
-  ldp  x19, x20, [sp], #16
-
-  ret
+mov x8, x0 // Preserve x0
+mov x9, x1 // Preserve x1
+
+//
+// If the EBC stack frame is smaller than or equal to 64 bytes, we know 
there
+// are no stacked arguments #9 and beyond that we need to copy to the 
native
+// stack. In this case, we can perform a tail call which is much more
+// efficient, since there is no need to touch the native stack at all.
+//
+sub x3, x2, x1  // Length = NewStackPointer - FramePtr
+cmp x3, #64
+b.gt1f
+
+adr x0, 0f
+sub x0, x0, x3, lsr #1
+br  x0
+
+ldr x7, [x9, #56]
+ldr x6, [x9, #48]
+ldr x5, [x9, #40]
+ldr x4, [x9, #32]
+ldr x3, [x9, #24]
+ldr x2, [x9, #16]
+ldr x1, [x9, #8]
+ldr x0, [x9]
+
+0:  br  x8
+
+//
+// More than 64 bytes: we need to build the full native stack frame and 
copy
+// the part of the VM stack exceeding 64 bytes (which may contain stacked
+// arguments) to the native stack
+//
+1:  stp x29, x30, [sp, #-16]!
+mov x29, sp
+
+//
+// Ensure that the stack pointer remains 16 byte aligned,
+// even if the size of the VM stack frame is not a multiple of 16
+//
+add x1, x1, #64 // Skip over [potential] reg params
+tbz x3, #3, 2f  // Multiple of 16?
+ldr x4, [x2, #-8]!  // No? Then push one word
+str x4, [sp, #-16]! // ... but use two slots
+b   3f
+
+2:  ldp x4, x5, [x2, #-16]!
+stp x4, x5, [sp, #-16]!
+3:  cmp x2, x1
+b.gt2b
+
+ldp x0, x1, [x9]
+ldp x2, x3, [x9, #16]
+ldp x4, x5, [x9, #32]
+ldp x6, x7, [x9, #48]
+
+blr x8
+
+mov sp, x29
+ldp x29, x30, [sp], #16
+ret
 
 //
 // EbcLLEbcInt

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 16:49, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 1 August 2016 at 16:18, Gao, Liming <liming@intel.com> wrote:
>> Ard:
>>   I don't think it is good way to define GCC_VISIBILITY_PROTECTED and apply 
>> it in EntryPointLib. We only need to expose _ModuleEntryPoint. It has been 
>> specified in LINK_FLAGS in tools_def.txt. Could we also specify its 
>> attribute in CC_FLAGS or LINK_FLAGS in tools_def.txt?
>>
>
> It seems this does the trick as well
>
> diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
> index 281af8a9bd33..02387d4f8d6f 100644
> --- a/BaseTools/Scripts/GccBase.lds
> +++ b/BaseTools/Scripts/GccBase.lds
> @@ -80,3 +80,7 @@ SECTIONS {
>  *(COMMON)
>}
>  }
> +
> +VERSION {
> +  { global: _ModuleEntryPoint*; };
> +};
>
>
> Note that * at the end: this is necessary since _ModuleEntryPoint will
> be called _ModuleEntryPoint.lto_priv.xxx in the LTO objects.
>

Hmm, looks like I spoke too soon. I don't know what I did wrong, but
this does not actually work.

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


Re: [edk2] [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 16:01, Shi, Steven  wrote:
> Ard,
> Where can I check out your v5 patch?
>

https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/gcc5-lto-v5

or

git://git.linaro.org/people/ard.biesheuvel/uefi-next.git gcc5-lto-v5

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


  1   2   3   4   5   6   7   8   9   10   >