Re: [edk2] Question about memory reservation from PrePi to DXE

2015-08-08 Thread Benjamin Herrenschmidt 
On Sat, 2015-08-08 at 17:12 +0200, Laszlo Ersek wrote:
> If that's indeed your point, then maybe it will help to look at the call
> tree "context" in the DXE core, where this function --
> CoreInitializeMemoryServices() -- is called from:
> 
>   DxeMain()[MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c]
> CoreInitializeMemoryServices() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
> AllocateRuntimeCopyPool()  
> [MdeModulePkg/Library/DxeCoreMemoryAllocationLib/MemoryAllocationLib.c]
> AllocateRuntimeCopyPool()  
> [MdeModulePkg/Library/DxeCoreMemoryAllocationLib/MemoryAllocationLib.c]
> ...
> CoreInitializeGcdServices()[MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
> 
> The CoreInitializeGcdServices() function *does* look at the memory
> allocation HOBs, and processes them so that the allocations show up in
> the UEFI memory map.

 .../...

> Yes, there are some memory allocations *between* those functions; I even
> spelled them out in the above call tree. Note however that these
> function calls are special: they are resolved to a DXE_CORE-specific
> memory allocation library instance (which is why I spelled out the
> pathnames to the right). 

Allright but that library in turn calls CoreAllocatePages() which as far
as I can tell is provided by MdeModulePkg/Core/Dxe/Mem/Page.c which,
unless I mis-read the code, will call FindFreePages() which will happily
pickup any pages in the region added by CoreInitializeMemoryServices().

Cheers,
Ben.


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

Re: [edk2] Question about memory reservation from PrePi to DXE

2015-08-08 Thread Benjamin Herrenschmidt 
On Sat, 2015-08-08 at 08:56 -0700, Andrew Fish wrote:
> If you really need to punch holes in the memory map, then you can use
> resource descriptors. 

Yes, I do need to punch holes in there, Laszlo explanation (which I
haven't fully digested yet) implies that using allocation hobs should
work which is what I wasn't sure of.

Essentially, I am on a platform/architecture which feeds a flat
device-tree to EDK and I need to honor the input reserved regions
as they cover bits of memory either already used by the HW for various
reasons or are occupied with another firmware that I'm not yet ready to
kill :-)

Cheers,
Ben.



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

Re: [edk2] Question about memory reservation from PrePi to DXE

2015-08-08 Thread Benjamin Herrenschmidt 
On Sat, 2015-08-08 at 17:12 +0200, Laszlo Ersek wrote:
> > What am I missing ? :-)
> 
> I think you were missing the conceptual hierarchy between the GCD
> memory
> space map and the UEFI memory map, and which HOBs produced in PEI
> (resource vs. allocation), and which services called in DXE and later
> (gDS->... vs. gBS->...), affect which level.
> 
> ... I sincerely hope that someone who participated in the design &
> implementation of these parts will chime in. In any case, the above is
> how I think about this stuff.

Many thanks for that in-depth explanation !

It makes me wonder whether we should copy/paste it into some FAQ or wiki
entry :-)

I will spend time digesting it and reading the specs in more details.

Cheers,
Ben.


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

Re: [edk2] Error on executing shell command ifconfig

2015-08-08 Thread Leekha Shaveta 
Does anyone tested network(ping/tftp) using E1000/NIC PCI card on Juno board?
Which LAN E1000 driver(source or any link) is used and tested for Intel NIC 
card?

Thanks and Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Friday, August 07, 2015 10:59 AM
To: 'Ye, Ting'; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Thanks Ting!

I have one "LanIntelE1000Dxe" code and using it, but this code is not yet 
tested on UEFI.
And as my network (ping/ifconfig) is not working, I am clueless about what 
exactly causing the issue.

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting
Sent: Friday, August 07, 2015 10:54 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: Re: [edk2] Error on executing shell command ifconfig

Hi Shaveta,

The upper layer drivers since SNP are available for several years and validated 
in multiple UEFI enabled platforms.
Sorry I don't know whether you can get the UEFI Intel E1000 NIC card driver. 
You may search the download center in Intel.com? Hope other guys in the mailing 
list know.

Best Regards,
Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com] 
Sent: Friday, August 07, 2015 1:18 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig


Upper layer drivers like SNP/MNP are also taken from EDK2 and not been tested 
on UEFI.

>From where can I get the complete code of Intel E1000 NIC card driver for UEFI?

Is such tested code available for use for UEFI?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 10:50 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

The #D and #C are zero which mean that this driver does not manage any device 
or child device. It looks the driver not function well.
You can also double check whether upper layer drivers like SNP, MNP, etc. ever 
manage any devices.

Best Regards,
Ye Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: Thursday, August 06, 2015 12:56 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for the reply.

This driver has not been tested on UEFI, but said to be tested on edk2.

On running drivers command I get following output:
Shell> drivers
 T   D
 Y C I
 P F A
DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH
===  = = = === === === ==
39 04040600 ? Y Y   0   0 Intel(R) PRO/1000 4.4.06 PCI-E  
MemoryMapped(0xB,0xFF80D000,0xFFBEA167)/FvFile(BB801A52-C90F-4EDE-91B2-82520888CBC3)

It seems that E1000 driver is getting loaded properly.
Correct understanding?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 5:56 AM
To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052
Subject: RE: Error on executing shell command ifconfig

Do you know whether the LanIntelE1000Dxe works properly? 
You may type "drivers" in shell to check connecting status of UEFI network 
drivers.

Best Regards,
Ye Ting


-Original Message-
From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com]
Sent: Wednesday, August 05, 2015 6:43 PM
To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for your inputs.

I tried adding the same as well and the following packages are now being added 
to the .dsc file:

  #
  # Networking stack
  #
  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf

Also e1000/NIC card driver's efi is getting loaded .
  # Intel E1000 driver
  INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf

Still I am getting same error:

Shell> ifconfig -l
Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found 
(3B95AA31-3793-434B-8667-C8070892E05E).

Can it be related to shell source/version? Or Lan/NIC/E1000 card driver?

Any hints would

Re: [edk2] Question about memory reservation from PrePi to DXE

2015-08-08 Thread Andrew Fish 

> On Aug 8, 2015, at 8:12 AM, Laszlo Ersek  wrote:
> 
> On 08/08/15 08:13, Benjamin Herrenschmidt wrote:
>> Hi !
>> 
>> I'm still trying to get my head around the internals of EDK here so
>> bear with me if there's an obvious answer that I missed ... :-)
>> 
>> I'm trying to understand how I can properly reserve bits of memory
>> from my PrePei or Pei so that DXE won't stomp on them.
>> 
>> To simplify the discussion, let's assume that I have a resource
>> descriptor of type EFI_RESOURCE_SYSTEM_MEMORY that cover, well .. all
>> of my system memory.
>> 
>> Then on top of that, I have a number of EFI_HOB_TYPE_MEMORY_ALLOCATION
>> HOBs that represent bits of that memory that I want to reserve.
> 
> Yes, this matches how I think of it.
> 

If you look at the PEI Services Table you will see that there is only Allocate 
Pages/Pool and not free. Basically the transition from PEI to DXE is the “de 
facto free” of this memory. 

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiPeiCis.h 

  EFI_PEI_ALLOCATE_PAGES AllocatePages;
  EFI_PEI_ALLOCATE_POOL   AllocatePool;

So the simple way to pass data between PEI and DXE is a HOB (Hand Off Block). 

If you really need to punch holes in the memory map, then you can use resource 
descriptors. 

Thanks,

Andrew Fish

>> From what I can see of the code in Gcd.c, this won't work, as
>> CoreInitializeMemoryServices() will not consider the allocation HOBs
>> before picking a piece of initial memory, and that initial memory will
>> be directed straight to the free list.
>> 
>> Or am I missing something ?
> 
> First, let's make sure I understand what you mean by "that initial
> memory will be directed straight to the free list" in
> CoreInitializeMemoryServices().
> 
> Do you mean the fact that CoreInitializeMemoryServices() does not look
> at EFI_HOB_TYPE_MEMORY_ALLOCATION HOBs, it "only" does some other (quite
> complex!) scanning, and then calls CoreAddMemoryDescriptor() at the end,
> with the comment
> 
>  //
>  // Declare the very first memory region, so the EFI Memory Services are 
> available.
>  //
> 
> without having looked at memory allocation HOBs?
> 
> If that's indeed your point, then maybe it will help to look at the call
> tree "context" in the DXE core, where this function --
> CoreInitializeMemoryServices() -- is called from:
> 
>  DxeMain()[MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c]
>CoreInitializeMemoryServices() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
>AllocateRuntimeCopyPool()  
> [MdeModulePkg/Library/DxeCoreMemoryAllocationLib/MemoryAllocationLib.c]
>AllocateRuntimeCopyPool()  
> [MdeModulePkg/Library/DxeCoreMemoryAllocationLib/MemoryAllocationLib.c]
>...
>CoreInitializeGcdServices()[MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
> 
> The CoreInitializeGcdServices() function *does* look at the memory
> allocation HOBs, and processes them so that the allocations show up in
> the UEFI memory map.
> 
> My point is that CoreInitializeMemoryServices() is just part of the
> story. Very soon after it other processing occurs (without intervening
> external code) that "primes" the memory map so that memory allocation
> HOBs are honored, before DXE modules can actually call memory allocation
> boot services.
> 
> Yes, there are some memory allocations *between* those functions; I even
> spelled them out in the above call tree. Note however that these
> function calls are special: they are resolved to a DXE_CORE-specific
> memory allocation library instance (which is why I spelled out the
> pathnames to the right). Those work differently from the run-of-the-mill
> allocations used during DXE (which are based on the boot services). So,
> I think the above should be self-consistent.
> 
>> So I need to "split" my EFI_RESOURCE_SYSTEM_MEMORY resource descriptor
>> HOBs to "avoid" reserved regions of memory before starting DXE,
>> correct ?
> 
> No. That would be terrible.
> 
> There are two concepts here, the DXE memory *space* map (more precisely
> called GCD memory space map), and the UEFI memory map. The GCD memory
> space map and surrounding APIs are specified in the Platform
> Initialization specs. The UEFI memory map is layered on top of the GCD
> memory space map, and it is treated (and the surrounding APIs are
> treated) in the UEFI spec.
> 
> - The UEFI memory map (the higher level concept) describes, roughly, how
>  ranges of the address space are used for *software* purposes. See
>  EFI_MEMORY_TYPE.
> 
> - The GCD memory space map (the lower level concept) deals more with
>  *hardware* properties; for example it describes where system memory,
>  MMIO, persistent memory, etc, *exist*. See EFI_GCD_MEMORY_TYPE.
> 
> There's a hierarchy between them; for example, the UEFI memory map
> cannot list an EfiBootServicesCode range that would fall onto
> EfiGcdMemoryTypeMemoryMappedIo in the underlying GCD memory space map.
> 
>

Re: [edk2] Question about memory reservation from PrePi to DXE

2015-08-08 Thread Laszlo Ersek 
On 08/08/15 08:13, Benjamin Herrenschmidt wrote:
> Hi !
>
> I'm still trying to get my head around the internals of EDK here so
> bear with me if there's an obvious answer that I missed ... :-)
>
> I'm trying to understand how I can properly reserve bits of memory
> from my PrePei or Pei so that DXE won't stomp on them.
>
> To simplify the discussion, let's assume that I have a resource
> descriptor of type EFI_RESOURCE_SYSTEM_MEMORY that cover, well .. all
> of my system memory.
>
> Then on top of that, I have a number of EFI_HOB_TYPE_MEMORY_ALLOCATION
> HOBs that represent bits of that memory that I want to reserve.

Yes, this matches how I think of it.

> From what I can see of the code in Gcd.c, this won't work, as
> CoreInitializeMemoryServices() will not consider the allocation HOBs
> before picking a piece of initial memory, and that initial memory will
> be directed straight to the free list.
>
> Or am I missing something ?

First, let's make sure I understand what you mean by "that initial
memory will be directed straight to the free list" in
CoreInitializeMemoryServices().

Do you mean the fact that CoreInitializeMemoryServices() does not look
at EFI_HOB_TYPE_MEMORY_ALLOCATION HOBs, it "only" does some other (quite
complex!) scanning, and then calls CoreAddMemoryDescriptor() at the end,
with the comment

  //
  // Declare the very first memory region, so the EFI Memory Services are 
available.
  //

without having looked at memory allocation HOBs?

If that's indeed your point, then maybe it will help to look at the call
tree "context" in the DXE core, where this function --
CoreInitializeMemoryServices() -- is called from:

  DxeMain()[MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c]
CoreInitializeMemoryServices() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
AllocateRuntimeCopyPool()  
[MdeModulePkg/Library/DxeCoreMemoryAllocationLib/MemoryAllocationLib.c]
AllocateRuntimeCopyPool()  
[MdeModulePkg/Library/DxeCoreMemoryAllocationLib/MemoryAllocationLib.c]
...
CoreInitializeGcdServices()[MdeModulePkg/Core/Dxe/Gcd/Gcd.c]

The CoreInitializeGcdServices() function *does* look at the memory
allocation HOBs, and processes them so that the allocations show up in
the UEFI memory map.

My point is that CoreInitializeMemoryServices() is just part of the
story. Very soon after it other processing occurs (without intervening
external code) that "primes" the memory map so that memory allocation
HOBs are honored, before DXE modules can actually call memory allocation
boot services.

Yes, there are some memory allocations *between* those functions; I even
spelled them out in the above call tree. Note however that these
function calls are special: they are resolved to a DXE_CORE-specific
memory allocation library instance (which is why I spelled out the
pathnames to the right). Those work differently from the run-of-the-mill
allocations used during DXE (which are based on the boot services). So,
I think the above should be self-consistent.

> So I need to "split" my EFI_RESOURCE_SYSTEM_MEMORY resource descriptor
> HOBs to "avoid" reserved regions of memory before starting DXE,
> correct ?

No. That would be terrible.

There are two concepts here, the DXE memory *space* map (more precisely
called GCD memory space map), and the UEFI memory map. The GCD memory
space map and surrounding APIs are specified in the Platform
Initialization specs. The UEFI memory map is layered on top of the GCD
memory space map, and it is treated (and the surrounding APIs are
treated) in the UEFI spec.

- The UEFI memory map (the higher level concept) describes, roughly, how
  ranges of the address space are used for *software* purposes. See
  EFI_MEMORY_TYPE.

- The GCD memory space map (the lower level concept) deals more with
  *hardware* properties; for example it describes where system memory,
  MMIO, persistent memory, etc, *exist*. See EFI_GCD_MEMORY_TYPE.

There's a hierarchy between them; for example, the UEFI memory map
cannot list an EfiBootServicesCode range that would fall onto
EfiGcdMemoryTypeMemoryMappedIo in the underlying GCD memory space map.

In the DXE phase and later, the GCD memory space map is manipulated with
DXE services (gDS->... functions). See "7.2 Global Coherency Domain
Services" in volume 2 of the Platform Init spec, v1.4. Whereas the UEFI
memory map is affected by memory allocation *boot* services (gBS->...
functions) that are defined in the UEFI spec.

... Clearly, what I wrote above contains a lot of hand-waving, but I
think it should be enough here for distinguishing the GCD memory space
map from the UEFI memory map, and seeing that the latter is based on top
of the former (or more-or-less "subdivides" the former).

Now, the "split" between these two concepts starts early; it is
considered even in PEI.

Namely, the resource descriptor HOBs that you produce during PEI (or
more generally called "the HOB producer phase") will prime the GCD
memory *space* map. For exampl

[edk2] [PATCH 4/5] ArmPlatformPkg/ArmVExpressPkg: add support for the Intel BDS

2015-08-08 Thread Ard Biesheuvel 
This adds support for the Intel BDS, by introducing a define
'USE_ARM_BDS' which defaults to TRUE, and can be overridden on
the build command line.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |  6 ++
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 13 +
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 15 +++
 3 files changed, 34 insertions(+)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 119ba3a0c61e..24e96e55165a 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -315,4 +315,10 @@ [Components.common]
   # Bds
   #
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+!if $(USE_ARM_BDS) == TRUE
   ArmPlatformPkg/Bds/Bds.inf
+!else
+  MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
+  MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+!endif
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
index 53e2ca8b0203..cb3a5c5f7581 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
@@ -201,7 +201,20 @@ [FV.FvMain]
   # Bds
   #
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+!if $(USE_ARM_BDS) == TRUE
   INF ArmPlatformPkg/Bds/Bds.inf
+!else
+  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
+  INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+
+  #
+  # TianoCore logo (splash screen)
+  #
+  FILE FREEFORM = PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
+   SECTION RAW = MdeModulePkg/Logo/Logo.bmp
+  }
+!endif
 
   # Legacy Linux Loader
   INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
index d2f8f5aa6d41..4096ee4b8ec7 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
@@ -12,6 +12,9 @@
 #
 #
 
+[Defines]
+  USE_ARM_BDS = TRUE
+
 [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
   GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
 
@@ -131,6 +134,13 @@ [LibraryClasses.common]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 
+!if $(USE_ARM_BDS) == FALSE
+  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
+  GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
+  
PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
+  
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+!endif
+
 [LibraryClasses.common.SEC]
   
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
   
ArmPlatformGlobalVariableLib|ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/Sec/SecArmPlatformGlobalVariableLib.inf
@@ -397,6 +407,11 @@ [PcdsFixedAtBuild.common]
   # Shell.
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
 
+!if $(USE_ARM_BDS) == FALSE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
+!endif
+
 [Components.common]
   MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
 
-- 
1.9.1

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

[edk2] [PATCH 5/5] ArmPlatformPkg/ArmVExpressPkg: enable UEFI Secure Boot

2015-08-08 Thread Ard Biesheuvel 
This allows the FVP target to be built with UEFI Secure Boot enabled,
by passing -D SECURE_BOOT_ENABLE to the build command line. Note that
you will need to disable the ARM BDS (-D USE_ARM_BDS=FALSE) or you will
not be able to enroll certificates, since the ARM BDS does not provide
a GUI to do so.

The FVP Fast model is recommended in this case, since the certificate
store is kept in NOR flash.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 12 ++
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf |  7 ++
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 25 

 3 files changed, 44 insertions(+)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 24e96e55165a..25714b0b0be0 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -260,7 +260,15 @@ [Components.common]
   #
   ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+!if $(SECURE_BOOT_ENABLE) == TRUE
+  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
+
+  
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
+  }
+  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+!else
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+!endif
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
@@ -278,7 +286,11 @@ [Components.common]
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
 
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+!if $(SECURE_BOOT_ENABLE) == TRUE
+  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf
+!else
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
+!endif
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
 !ifndef ARM_FOUNDATION_FVP
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
index cb3a5c5f7581..4a5a69fadc12 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
@@ -139,6 +139,9 @@ [FV.FvMain]
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+!if $(SECURE_BOOT_ENABLE) == TRUE
+  INF 
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+!endif
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
@@ -159,7 +162,11 @@ [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
 !ifndef ARM_FOUNDATION_FVP
   INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
 !endif
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
index 4096ee4b8ec7..273dcf5902c4 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
@@ -14,6 +14,7 @@
 
 [Defines]
   USE_ARM_BDS = TRUE
+  SECURE_BOOT_ENABLE  = FALSE
 
 [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
   GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
@@ -131,8 +132,22 @@ [LibraryClasses.common]
   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
+  #
+  # Secure Boot dependencies
+  #
+!if $(SECURE_BOOT_ENABLE) == TRUE
+  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+
+  # re-use the UserPhysicalPresent() dummy implementation from the ovmf tree
+  PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
+!else
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+!endif
 
 !if $(USE_ARM_BDS) == FALSE
   CapsuleLib|MdeModulePkg/Libra

[edk2] [PATCH 3/5] ArmPlatformPkg/PlatformIntelBdsLib: add splash screen support

2015-08-08 Thread Ard Biesheuvel 
Add a call to EnableQuietBoot () to BdsPlatformPolicyBehavior(),
so that a splash screen is shown in case one is present under the
correct GUID in the FV, and we have graphics support.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 5 +
 ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 1 +
 2 files changed, 6 insertions(+)

diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
index 9ba95d989666..98d5b277a636 100644
--- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
+++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
@@ -311,6 +311,11 @@ PlatformBdsPolicyBehavior (
 
   Status = PlatformBdsConnectConsole ();
   ASSERT_EFI_ERROR (Status);
+
+  //
+  // Show the splash screen.
+  //
+  EnableQuietBoot (PcdGetPtr (PcdLogoFile));
 }
 
 /**
diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf 
b/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
index d47298d01a81..a18c5ea71f70 100644
--- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
+++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
@@ -58,6 +58,7 @@ [Pcd]
   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths
   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile
 
 [Protocols]
   gEfiDevicePathFromTextProtocolGuid
-- 
1.9.1

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

[edk2] [PATCH 1/5] ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency

2015-08-08 Thread Ard Biesheuvel 
The Intel BDS platform library still depends on the ARM BDS specific
BdsLib. So replace its invocations with GenericBdsLib counterparts,
and fix up where needed, so that we can drop the dependency.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 21 
++--
 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h  |  1 -
 ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |  1 -
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
index c82f27fb4edd..739704727945 100644
--- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
+++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
@@ -63,8 +63,11 @@ GetConsoleDevicePathFromVariable (
   CHAR16*   NextDevicePathStr;
   EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL  *EfiDevicePathFromTextProtocol;
 
-  Status = GetGlobalEnvironmentVariable (ConsoleVarName, NULL, NULL, 
(VOID**)&DevicePathInstances);
-  if (EFI_ERROR(Status)) {
+  Status = EFI_SUCCESS;
+  Size = 0;
+
+  DevicePathInstances = BdsLibGetVariableAndSize (ConsoleVarName, 
&gEfiGlobalVariableGuid, &Size);
+  if (DevicePathInstances == NULL) {
 // In case no default console device path has been defined we assume a 
driver handles the console (eg: SimpleTextInOutSerial)
 if ((DefaultConsolePaths == NULL) || (DefaultConsolePaths[0] == L'\0')) {
   *DevicePaths = NULL;
@@ -74,8 +77,6 @@ GetConsoleDevicePathFromVariable (
 Status = gBS->LocateProtocol (&gEfiDevicePathFromTextProtocolGuid, NULL, 
(VOID **)&EfiDevicePathFromTextProtocol);
 ASSERT_EFI_ERROR(Status);
 
-DevicePathInstances = NULL;
-
 // Extract the Device Path instances from the multi-device path string
 while ((DefaultConsolePaths != NULL) && (DefaultConsolePaths[0] != L'\0')) 
{
   NextDevicePathStr = StrStr (DefaultConsolePaths, L";");
@@ -141,7 +142,15 @@ InitializeConsolePipe (
   while (ConsoleDevicePaths != NULL) {
 DevicePath = GetNextDevicePathInstance (&ConsoleDevicePaths, &Size);
 
-Status = BdsConnectDevicePath (DevicePath, Handle, NULL);
+Status = BdsLibConnectDevicePath (DevicePath);
+if (!EFI_ERROR (Status)) {
+  //
+  // If BdsLibConnectDevicePath () succeeded, *Handle must have a non-NULL
+  // value. So ASSERT that this is the case.
+  //
+  gBS->LocateDevicePath (&gEfiDevicePathProtocolGuid, &DevicePath, Handle);
+  ASSERT (*Handle != NULL);
+}
 DEBUG_CODE_BEGIN();
   if (EFI_ERROR(Status)) {
 // We convert back to the text representation of the device Path
@@ -171,7 +180,7 @@ InitializeConsolePipe (
   if (*Interface == NULL) {
 Status = gBS->LocateHandleBuffer (ByProtocol, Protocol, NULL, &NoHandles, 
&Buffer);
 if (EFI_ERROR (Status)) {
-  BdsConnectAllDrivers ();
+  BdsLibConnectAll ();
   Status = gBS->LocateHandleBuffer (ByProtocol, Protocol, NULL, 
&NoHandles, &Buffer);
 }
 
diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h 
b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h
index a244ac913255..7122d58be7d7 100644
--- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h
+++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h
@@ -19,7 +19,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf 
b/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
index 07de4cae4824..d47298d01a81 100644
--- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
+++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
@@ -44,7 +44,6 @@ [Packages]
 [LibraryClasses]
   BaseLib
   BaseMemoryLib
-  BdsLib
   DebugLib
   DevicePathLib
   MemoryAllocationLib
-- 
1.9.1

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

[edk2] [PATCH 0/5] secure boot support for ARM FVP

2015-08-08 Thread Ard Biesheuvel 
This series adds support for using the Intel BDS with ArmVExpress-FVP,
and for building it with UEFI Secure Boot enabled.

Note that the former is a prerequisite of the latter, since the ARM BDS
has no GUI for enrolling certificates and enabling secure boot.

Patch #1 removes the PlatformIntelBdsLIb dependency on BdsLib, which is
ARM BDS specific. (This patch has been sent out before as an RFC, and
reviewed by Laszlo, but I had to add a 'Status = EFI_SUCCESS;' to
GetConsoleDevicePathFromVariable () to fix a RELEASE build error, so
I dropped the R-b)

Patch #2 fixes a bug in some debug code that clobbers a EFI_STATUS var
in the error path that is supposed to report it to the user.

Patch #3 adds quiet boot/splash screen support to our PlatformIntelBdsLib

Patch #4 enables the Intel BDS build of ArmVExpress-FVP, by introducing
a define 'USE_ARM_BDS' which defaults to TRUE but can be disabled on the
build command line to use the Intel BDS instead.

Patch #5 enables the Secure Boot build of ArmVExpress-FVP, by introducing
a define 'SECURE_BOOT_ENABLE' which defaults to FALSE but can be enabled
on the build command line.

Ard Biesheuvel (5):
  ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency
  ArmPlatformPkg/PlatformIntelBdsLib: fix error handling
  ArmPlatformPkg/PlatformIntelBdsLib: add splash screen support
  ArmPlatformPkg/ArmVExpressPkg: add support for the Intel BDS
  ArmPlatformPkg/ArmVExpressPkg: enable UEFI Secure Boot

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 18 
+
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  | 20 
++
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  | 40 

 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 36 
--
 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h  |  1 -
 ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |  2 +-
 6 files changed, 104 insertions(+), 13 deletions(-)

-- 
1.9.1

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

[edk2] [PATCH 2/5] ArmPlatformPkg/PlatformIntelBdsLib: fix error handling

2015-08-08 Thread Ard Biesheuvel 
In InitializeConsolePipe (), we clobber the Status variable in the
error handling path that reports Status in its output. Instead,
use a NULL check on the LocateProtocol () output argument.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
index 739704727945..9ba95d989666 100644
--- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
+++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
@@ -154,12 +154,12 @@ InitializeConsolePipe (
 DEBUG_CODE_BEGIN();
   if (EFI_ERROR(Status)) {
 // We convert back to the text representation of the device Path
-EFI_DEVICE_PATH_TO_TEXT_PROTOCOL* DevicePathToTextProtocol;
-CHAR16* DevicePathTxt;
-EFI_STATUS Status;
+EFI_DEVICE_PATH_TO_TEXT_PROTOCOL  *DevicePathToTextProtocol;
+CHAR16*DevicePathTxt;
 
-Status = gBS->LocateProtocol(&gEfiDevicePathToTextProtocolGuid, NULL, 
(VOID **)&DevicePathToTextProtocol);
-if (!EFI_ERROR(Status)) {
+DevicePathToTextProtocol = NULL;
+gBS->LocateProtocol(&gEfiDevicePathToTextProtocolGuid, NULL, (VOID **) 
&DevicePathToTextProtocol);
+if (DevicePathToTextProtocol != NULL) {
   DevicePathTxt = DevicePathToTextProtocol->ConvertDevicePathToText 
(DevicePath, TRUE, TRUE);
 
   DEBUG((EFI_D_ERROR,"Fail to start the console with the Device Path 
'%s'. (Error '%r')\n", DevicePathTxt, Status));
-- 
1.9.1

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

Re: [edk2] [PATCH] BaseTools: Fix GCC49 build failure

2015-08-08 Thread Ard Biesheuvel 
On 7 August 2015 at 22:15, Scott Duplichan  wrote:
> Some gnu linkers used with GCC44, such as GNU ld 2.19.1, require a
> --defsym= command line option to precede the --script= option in
> order for the definition to be available for use by the script.
> Move the --defsym= command line option to satisfy this requirement
> and avoid a GCC44 build failure.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Scott Duplichan 

For consistency, we should probably invert the order for all versions,
but it can wait until later.

Reviewed-by: Ard Biesheuvel 

> ---
>
> I found this using a Windows hosted GCC 4.4.7 and Shell build:
> build.exe -p d:\edk2build\edk2\ShellPkg\ShellPkg.dsc -b DEBUG -t GCC44 -n 16 
> -a X64
> "ld" -o 
> d:\edk2build\edk2\Build\Shell\DEBUG_GCC44\X64\ShellPkg\Application\Shell\Shell\DEBUG\Shell.dll
>  -nostdlib -n -q --gc-sections -z common-page-size=0x20 --entry 
> _ModuleEntryPoint -u _ModuleEntryPoint -Map 
> d:\edk2build\edk2\Build\Shell\DEBUG_GCC44\X64\ShellPkg\Application\Shell\Shell\DEBUG/Shell.map
>  -melf_x86_64 --oformat=elf64-x86-64 --start-group  
> @d:\edk2build\edk2\Build\Shell\DEBUG_GCC44\X64\ShellPkg\Application\Shell\Shell\OUTPUT\static_library_files.lst
>  --end-group --script=d:\edk2build\edk2\basetools/Scripts/GccBase.lds 
> --defsym=PECOFF_HEADER_SIZE=0x228
> d:\edk2build\edk2\basetools/Scripts/GccBase.lds:1: undefined symbol 
> `PECOFF_HEADER_SIZE' referenced in expression
> ---
>
>  BaseTools/Conf/tools_def.template | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index eeb488f..806e6e6 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -3850,9 +3850,9 @@ DEFINE GCC44_X64_CC_FLAGS= 
> DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-p
>  DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
> common-page-size=0x20
>  DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
> --entry ReferenceAcpiTable -u ReferenceAcpiTable
>  DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
> --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> -DEFINE GCC44_IA32_DLINK2_FLAGS   = DEF(GCC_DLINK2_FLAGS_COMMON) 
> --defsym=PECOFF_HEADER_SIZE=0x220
> +DEFINE GCC44_IA32_DLINK2_FLAGS   = --defsym=PECOFF_HEADER_SIZE=0x220 
> DEF(GCC_DLINK2_FLAGS_COMMON)
>  DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)  
> -melf_x86_64 --oformat=elf64-x86-64
> -DEFINE GCC44_X64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
> --defsym=PECOFF_HEADER_SIZE=0x228
> +DEFINE GCC44_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 
> DEF(GCC_DLINK2_FLAGS_COMMON)
>  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
>
>  DEFINE GCC45_IA32_CC_FLAGS   = DEF(GCC44_IA32_CC_FLAGS)
>
> ___
> 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