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

2015-08-08 Thread Ard Biesheuvel
On 7 August 2015 at 22:15, Scott Duplichan sc...@notabs.org 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 sc...@notabs.org

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

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

 ---

 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


[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 ard.biesheu...@linaro.org
---
 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


[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 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 ard.biesheu...@linaro.org
---
 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 {
+LibraryClasses
+  
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

[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 ard.biesheu...@linaro.org
---
 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 ard.biesheu...@linaro.org
---
 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 Protocol/DevicePathToText.h
 
 #include Library/BaseMemoryLib.h
-#include Library/BdsLib.h
 #include Library/DebugLib.h
 #include Library/DevicePathLib.h
 #include Library/UefiBootServicesTableLib.h
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 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 ard.biesheu...@linaro.org
---
 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


Re: [edk2] [RFC PATCH 0/4] unify GCC command line options

2015-08-13 Thread Ard Biesheuvel
On 13 August 2015 at 08:27, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 12 August 2015 at 23:48, David Woodhouse dw...@infradead.org wrote:
 On Wed, 2015-08-12 at 09:08 +0200, Ard Biesheuvel wrote:
 Is there any reason these are kept out of sync? Are UNIXGCC and CYGGCC
 known to be widely used in some particular environment? If not, I
 think it makes sense to merge them, i.e., retain the UNIXGCC and
 CYGGCC toolchain names, but make them use the same options for IA32
 and X64 as GCC44 - GCC49 do. (UNIXGCC and CYGGCC are unversioned, so
 it is unclear which GCC version they expect anyway)

 That would seem to make sense.

 FWIW it doesn't actually build with MinGW (which is what UNIXGCC is)
 these days anyway. You might make it work with -fstack-check=specific:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169


 OK noted

 However, building with i686-w64-mingw32-gcc produces lots of
 -Wint-to-pointer-cast issues, so I am not sure how this is supposed to
 work.
 Is this the wrong mingw version to use? I guess UINTN is typedef'ed to
 'unsigned long long' on LLP64, otherwise the assumption that
 sizeof(UINTN) == sizeof(VOID*) that is made throughout the EDK2 code
 base obviously does not hold.


OK, never mind. I should be using x86_64-w64-mingw32-gcc to build for X64
Sorry for the noise
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2] BaseTools IA32/X64: prevent .eh_frame sections from being generated

2015-08-12 Thread Ard Biesheuvel
After the recent GNU linker script changes, the following warning is
emitted many times during the OVMF build:

BFD: ...: warning: Empty loadable segment detected, is this intentional ?

This is caused by the fact that, now that the section layout has changed
somewhat, the .eh_frame section is assigned an ELF segment of its own,
which ends up with no contents at all after we strip the .eh_frame
section from the output. (Note that the program headers that contain the
segment information are completely irrelevant to us since the PE/COFF
conversion does not rely on them.)

Since we only retain the .eh_frame data for external debugging, and not
for things like stack unwinding or generating backtraces at runtime, we
can remedy the situation by passing -fno-asynchronous-unwind-tables on
the GCC command line. This option instructs the compiler to emit the
unwind data into a debug section called .debug_frame instead of into
.eh_frame.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Laszlo Ersek ler...@redhat.com
Build-tested-by: Laszlo Ersek ler...@redhat.com
---
v2: give IA32 the same treatment as X86
add Laszlo's acks
---
 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 6e2d4909b9fc..859fbe14ad59 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3839,8 +3839,8 @@ DEFINE GCC_ARM_RC_FLAGS= -I binary -O 
elf32-littlearm -B arm
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
 DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include 
AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
-DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32
-DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large
+DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
+DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
common-page-size=0x20
 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
-- 
1.9.1

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


Re: [edk2] [PATCH v2] BaseTools IA32/X64: prevent .eh_frame sections from being generated

2015-08-13 Thread Ard Biesheuvel
On 13 August 2015 at 07:44, Gao, Liming liming@intel.com wrote:
 Reviewed-by: Liming Gao liming@intel.com


Thanks

Committed as SVN r18217

-- 
Ard.

 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: Thursday, August 13, 2015 1:19 PM
 To: edk2-devel@lists.01.org; ler...@redhat.com; Liu, Yingke D
 Cc: Gao, Liming; Ard Biesheuvel
 Subject: [PATCH v2] BaseTools IA32/X64: prevent .eh_frame sections from being 
 generated

 After the recent GNU linker script changes, the following warning is emitted 
 many times during the OVMF build:

 BFD: ...: warning: Empty loadable segment detected, is this intentional ?

 This is caused by the fact that, now that the section layout has changed 
 somewhat, the .eh_frame section is assigned an ELF segment of its own, which 
 ends up with no contents at all after we strip the .eh_frame section from the 
 output. (Note that the program headers that contain the segment information 
 are completely irrelevant to us since the PE/COFF conversion does not rely on 
 them.)

 Since we only retain the .eh_frame data for external debugging, and not for 
 things like stack unwinding or generating backtraces at runtime, we can 
 remedy the situation by passing -fno-asynchronous-unwind-tables on the GCC 
 command line. This option instructs the compiler to emit the unwind data into 
 a debug section called .debug_frame instead of into .eh_frame.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 Reviewed-by: Laszlo Ersek ler...@redhat.com
 Build-tested-by: Laszlo Ersek ler...@redhat.com
 ---
 v2: give IA32 the same treatment as X86
 add Laszlo's acks
 ---
  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 6e2d4909b9fc..859fbe14ad59 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3839,8 +3839,8 @@ DEFINE GCC_ARM_RC_FLAGS= -I binary -O 
 elf32-littlearm -B arm
  DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
 aarch64 --rename-section .data=.hii

  DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
 -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c 
 -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 -DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
 -malign-double -fno-stack-protector -D EFI32
 -DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
 -fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
 -mno-red-zone -Wno-address -mcmodel=large
 +DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
 +DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
 -fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
 -mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
  DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
 common-page-size=0x20
  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
 --
 1.9.1

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


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

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 21:16, David Woodhouse dw...@infradead.org wrote:
 See http://www.infradead.org/rpr.html
 X-SRS-Rewrite: SMTP reverse-path rewritten from dw...@infradead.org by 
 twosheds.infradead.org
 See http://www.infradead.org/rpr.html


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

 Not for testing LLP64, no.

 How/who is this helping?

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


Indeed. I don't use Windows or have access to any MS toolchains, so
this is basically the only way to make sure my code is LLP64 clean.

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

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

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


Why *must* we have the version encoded into the name? For GCC4x, the
differences are so minor that it is just maintenance overhead imo. I
used CLANG35 instead of CLANG per your request, but I am definitely
not going to add CLANG36 CLANG37 etc unless there is a real need.

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

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


Well, I would think that deprecating toolchains that don't support C99
is the first step towards allowing C99.

We are kidding ourselves if we think that 'present in
tools_def.template' and 'supported' are the same thing. In other
words, many of these toolchains are already deprecated since nobody
uses them, and they may not work anymore at all.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


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

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

 No, you can't really.

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

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


By the same logic, why on earth do we insist on retaining support for
GCC44 and GCC45?

Note that it is not about the linker path, but about the options that
we pass, for instance to get 4 KB section alignment. MinGW does not
need a linker script for this, you can simply set --section-alignment
and --file-alignment on the command line.

As for the PE/COFF support: if you are incorporating PE/COFF binary
static libraries into your build, you need a native PE/COFF toolchain.
But in general, I think the ELF to PE/COFF conversion is not the most
elegant step in the build, and I would prefer to avoid it if possible
(only, there is no PE/COFF support in the GNU tools for ARM or
AARCH64)

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

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

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

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


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


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

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

  . . .

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

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

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

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

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


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

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

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

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

so I will add this change to v2

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

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

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

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

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


OK, this sucks.

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

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

-- 
Ard

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

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

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


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


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

 --
 2.1.4

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


[edk2] [PATCH v2 07/16] BaseTools GCC: use leading underscore for symbol names where appropriate

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
1.9.1

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Patch #3 removes an unused DEFINE from tools_def

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

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

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

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

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

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

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

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

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

Patch #13 as #11 but for the linker.

Patch #14 unifies the ASM flags for all archs.

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

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

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

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

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

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

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

-- 
1.9.1

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


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

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

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

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

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


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

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


Good point, thanks.


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

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

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

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

 +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
 +!if $(TOOLCHAIN) == UNIXGCC
 +  GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment
 +0x1000 !else
 +  GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000 !endif
 +
  
 
  #
  # SKU Identification section - list of all SKU IDs supported by this 
 Platform.
 --
 1.9.1

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


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

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

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

 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

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

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


Re: [edk2] [PATCH 14/15] ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Cc: Leif Lindholm leif.lindh...@linaro.org
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

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

 ---
  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 5 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 5 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 5 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 5 -
  4 files changed, 16 insertions(+), 4 deletions(-)

 diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc 
 b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
 index 09ec5b3..f5af426 100644
 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
 +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
 @@ -220,7 +220,10 @@ [Components.common]
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
EmbeddedPkg/SerialDxe/SerialDxe.inf

 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

#
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
 index c1e3513..c76d729 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
 @@ -233,7 +233,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

 MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
 index 119ba3a..71c794b 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
 @@ -262,7 +262,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

 MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
 index 37f3648..72103e2 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
 @@ -245,7 +245,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

 MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
 --
 1.9.5.msysgit.0

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


Re: [edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 14:30, Haojian Zhuang haojian.zhu...@linaro.org wrote:
 On Tue, 2015-08-18 at 11:43 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 11:31, Haojian Zhuang haojian.zhu...@linaro.org wrote:
  On Tue, 2015-08-18 at 11:22 +0200, Ard Biesheuvel wrote:
  On 18 August 2015 at 11:04, Haojian Zhuang haojian.zhu...@linaro.org 
  wrote:
   Support multiple PL061 controllers.
  
   Contributed-under: TianoCore Contribution Agreement 1.0
   Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
   ---
ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 
   ++---
.../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
3 files changed, 96 insertions(+), 54 deletions(-)
  
   diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
   b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
   index e8a2094..3027656 100644
   --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
   +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
   @@ -28,6 +28,7 @@
#include Drivers/PL061Gpio.h
  
BOOLEAN mPL061Initialized = FALSE;
   +PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;
  
/**
  Function implementations
   @@ -38,20 +39,31 @@ PL061Identify (
  VOID
  )
{
   -  // Check if this is a PrimeCell Peripheral
   -  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
   -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
   -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
   -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
   -return EFI_NOT_FOUND;
   +  UINTNIndex;
   +  UINT32   RegisterBase;
 
  Why is this a 32-bit value?
 
  All registers in PL061 are 32-bit. So we don't need to define UINTN at
  here.
 

 So what happens if the GPIO controller is mapped above 4 GB in physical 
 memory?


 OK. I'll use 64-bit register base at here. But the original PL061 driver
 is also using 32-bit register base. We could get the definition from
 PL061Gpio.h
 #define PL061_GPIO_DATA_REG ((UINT32)PcdGet32
 (PcdPL061GpioBase) + 0x000)


OK. We should also fix that at some point, but for new code, please
don't make any 32-bit assumptions

   @@ -329,6 +367,9 @@ PL061InstallProtocol (
  //
  ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, gEmbeddedGpioProtocolGuid);
  
   +  Status = gBS-LocateProtocol (gPlatformGpioProtocolGuid, NULL, 
   (VOID **)mPL061PlatformGpio);
   +  ASSERT_EFI_ERROR (Status);
   +
 
  We should fall back to using the PCD if the protocol cannot be found.
  This way, we won't break existing users.
 
 
  I was intended to use fallback. But I think it's not good enough.
 
  1. If anyone defines the PCD register base in dec file. The fallback
  mechanism will be broken.
 

 Well, you would only look at the PCD if the protocol is not installed,
 so I don't see how that would change anything compared to the current
 situation.

  2. Since every driver is built as module, we must create the driver
  dependency.
 

 Please try and use a BEFORE ... depex instead, you can put it in your
 platform GPIO DXE with the file GUID of the PL061 DXE driver.


 I tried to use BEFORE in inf. Here's the content in platform gpio inf.
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = HiKeyGpio
   FILE_GUID  = b51a851c-7bf7-463f-b261-cfb158b7f699
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
   ENTRY_POINT= HiKeyGpioEntryPoint

 [Protocols]
   gPlatformGpioProtocolGuid

 [Depex]
   BEFORE gEmbeddedGpioProtocolGuid


You need to use the file GUID of PL061 DXE here. Perhaps you should
add it as a new GUID definition in the HiSiPkg .dec, with the value
5c1997d7-8d45-4f21-af3c-2206b8ed8bec


 And here's updated PL061 driver.

 PL061InstallProtocol (
   IN EFI_HANDLE ImageHandle,
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
   EFI_STATUSStatus;
   EFI_HANDLEHandle;
   GPIO_CONTROLLER   *GpioController;

   //
   // Make sure the Gpio protocol has not been installed in the system
 yet.
   //
   ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, gEmbeddedGpioProtocolGuid);

   Status = gBS-LocateProtocol (gPlatformGpioProtocolGuid, NULL, (VOID
 **)mPL061PlatformGpio);
   DEBUG ((EFI_D_ERROR, #%a, %d, Status:%r\n, __func__, __LINE__,
 Status));
   if (EFI_ERROR (Status)  (Status == EFI_NOT_FOUND)) {
 // Create the mPL061PlatformGpio
 mPL061PlatformGpio = (PLATFORM_GPIO_CONTROLLER *)AllocateZeroPool
 (sizeof (PLATFORM_GPIO_CONTROLLER) + sizeof (GPIO_CONTROLLER));
 if (mPL061PlatformGpio == NULL) {
   DEBUG ((EFI_D_ERROR, %a: failed to allocate
 PLATFORM_GPIO_CONTROLLER\n, __func__));
   return EFI_BAD_BUFFER_SIZE;
 }

 mPL061PlatformGpio-GpioCount = PL061_GPIO_PINS;
 mPL061PlatformGpio-GpioControllerCount = 1;
 mPL061PlatformGpio-GpioControllerSize = sizeof (GPIO_CONTROLLER

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

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Since Variable driver has been updated to consume the separated VarCheckLib.

 Cc: Leif Lindholm leif.lindh...@linaro.org
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

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

 ---
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 index d2f8f5a..dc69bbb 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 @@ -130,6 +130,7 @@ [LibraryClasses.common]


 TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf

 AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf

  [LibraryClasses.common.SEC]

 ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
 --
 1.9.5.msysgit.0

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


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

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Since Variable driver has been updated to consume the separated VarCheckLib.

 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

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

 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index 7bba6eb..8372c58 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -134,6 +134,7 @@ [LibraryClasses.common]

 TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf

 AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
  !endif
 +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf

  [LibraryClasses.common.SEC]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
 --
 1.9.5.msysgit.0

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


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

2015-08-18 Thread Ard Biesheuvel
On 8 August 2015 at 14:00, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 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.


Ping?

 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


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 14:12, Leif Lindholm leif.lindh...@linaro.org wrote:
 On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
 On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
  Instead of omitting some drivers that are known to break the Foundation
  model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
  simply fail to load without interfering with the boot.
 
  This way, we can use the same boot image for both models.
 

 Ping?

 Basicallt looks good to me, but I thought I'd wait for Ryan to comment
 (and he's on holiday through this week).

 Just to confirm - the Mmio probes just return zeroes in the Foundation
 model, rather than aborting?


Foundation model output:

WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c050fe0.
WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c1f0fe0.

Note sure what these reads return, but in each case, the first byte
already differs from the expected value so the init aborts.

I know that this would still be sufficient to blow up on a real
system, but thankfully the model does not model /that/ :-)


  Ard Biesheuvel (3):
ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
  initializing
ArmPlatformPkg/FVP: unify support for Foundation and Base models
 
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
  -
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
  
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 
  +
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 19 
  +++
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 13 
  +
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
  +
   ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
  +
   8 files changed, 64 insertions(+), 18 deletions(-)
 
  --
  1.9.1
 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 Instead of omitting some drivers that are known to break the Foundation
 model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
 simply fail to load without interfering with the boot.

 This way, we can use the same boot image for both models.


Ping?

 Ard Biesheuvel (3):
   ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
   ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
 initializing
   ArmPlatformPkg/FVP: unify support for Foundation and Base models

  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 19 
 +++
  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 13 
 +
  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
 +
  ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
 +
  8 files changed, 64 insertions(+), 18 deletions(-)

 --
 1.9.1

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


Re: [edk2] [PATCH 0/2] AARCH64 tiny code model support

2015-08-18 Thread Ard Biesheuvel
On 10 August 2015 at 12:27, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 The AARCH64 GCC builds use the GCC large code model by default, simply
 because it is the code model that requires the least amount of hacking
 to produce code that supports the PE/COFF conversion applied by Tianocore.

 However, it is suboptimal in more than one way:
 - each symbol reference requires a PC-relative literal load (to obtain the
   address of the memory location that stores the address of the symbol) and 8
   bytes to store the address itself, so it uses more space than necessary;
 - loading the symbol address may stall on the D-cache
 - each symbol address is an absolute address which requires fixing up by the
   PE/COFF loader
 - the large model is not recommended by the GCC developers, and not used very
   widely so it does not receive a lot of testing coverage.

 Now that we can support relative AARCH64 relocations, we can actually switch 
 to
 the GCC tiny code model, which does away with the literals, and simply uses
 PC-relative references to refer to the symbol directly. This does impose a
 1 MB size limit on modules, but this limit is exceeded only very rarely, and
 we can work around it by switching to the small or large model in that case.

 Patch #1 overrides the BuildOptions for the DEBUG Shell build to use the small
 model, since its size exceeds the 1 MB limit.

 Patch #2 sets the AARCH64 code model to 'tiny' by default.

 For the ArmVirtQemu AARCH64 RELEASE build, the size reduction is 10% before
 compression, 3% after compression, with the number of PE/COFF fixups reduced
 by 80% (see below for details)



Ping?


 Ard Biesheuvel (2):
   ArmVirtPkg: build our DEBUG Shell using the small code model
   BaseTools AARCH64: use tiny code model by default

  ArmVirtPkg/ArmVirt.dsc.inc| 9 +
  BaseTools/Conf/tools_def.template | 2 +-
  2 files changed, 10 insertions(+), 1 deletion(-)


 Size and offset of the compressed inner FV, with the uncompressed size
 near the bottom, using the large code model:

 
 File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
 File Offset:  0x0001C8B8
 File Length:  0x0009562C
 File Attributes:  0x00
 File State:   0xF8
 EFI_FILE_DATA_VALID
 File Type:0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
 
   Type:  EFI_SECTION_GUID_DEFINED
   Size:  0x00095614
   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf

   DataOffset: 0x0018
   Attributes: 0x0001
 
   Type:  EFI_SECTION_RAW
   Size:  0x000C
 
   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
   Size:  0x003FD4C4
 


 Size and offset of the compressed inner FV, with the uncompressed size
 near the bottom, using the tiny code model:

 
 File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
 File Offset:  0x0001BDF8
 File Length:  0x000915F0
 File Attributes:  0x00
 File State:   0xF8
 EFI_FILE_DATA_VALID
 File Type:0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
 
   Type:  EFI_SECTION_GUID_DEFINED
   Size:  0x000915D8
   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf

   DataOffset: 0x0018
   Attributes: 0x0001
 
   Type:  EFI_SECTION_RAW
   Size:  0x000C
 
   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
   Size:  0x0039B484
 

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


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

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

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

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


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

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

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

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

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


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

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

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


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

-- 
Ard.


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

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

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

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

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

 Patch #3 removes an unused DEFINE from tools_def

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

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

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

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

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

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

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

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

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

 Patch #13 as #11 but for the linker.

 Patch #14 unifies the ASM flags for all archs.

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

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

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

[edk2] [PATCH] ShellBinPkg: Arm/AArch64 Shell binary update.

2015-08-19 Thread Ard Biesheuvel
The binaries of ShellBinPkg are generated with ShellPkg project 18222.

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

These are built with the tiny code model, note the code size reduction
for AARCH64.

Branch:
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/binshell

 ShellBinPkg/MinUefiShell/AArch64/Shell.efi | Bin 408416 - 387808 bytes
 ShellBinPkg/MinUefiShell/Arm/Shell.efi | Bin 324480 - 330208 bytes
 ShellBinPkg/UefiShell/AArch64/Shell.efi| Bin 945152 - 887136 bytes
 ShellBinPkg/UefiShell/Arm/Shell.efi| Bin 757728 - 769536 bytes
 4 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/ShellBinPkg/MinUefiShell/AArch64/Shell.efi 
b/ShellBinPkg/MinUefiShell/AArch64/Shell.efi
index 7f63d86230e8..d5756e101342 100755
Binary files a/ShellBinPkg/MinUefiShell/AArch64/Shell.efi and 
b/ShellBinPkg/MinUefiShell/AArch64/Shell.efi differ
diff --git a/ShellBinPkg/MinUefiShell/Arm/Shell.efi 
b/ShellBinPkg/MinUefiShell/Arm/Shell.efi
index 782489af6960..8a7d7e5b7946 100755
Binary files a/ShellBinPkg/MinUefiShell/Arm/Shell.efi and 
b/ShellBinPkg/MinUefiShell/Arm/Shell.efi differ
diff --git a/ShellBinPkg/UefiShell/AArch64/Shell.efi 
b/ShellBinPkg/UefiShell/AArch64/Shell.efi
index 5a44a8ca6189..056da8d2932a 100755
Binary files a/ShellBinPkg/UefiShell/AArch64/Shell.efi and 
b/ShellBinPkg/UefiShell/AArch64/Shell.efi differ
diff --git a/ShellBinPkg/UefiShell/Arm/Shell.efi 
b/ShellBinPkg/UefiShell/Arm/Shell.efi
index 5a61df621047..afa91c4d6caf 100755
Binary files a/ShellBinPkg/UefiShell/Arm/Shell.efi and 
b/ShellBinPkg/UefiShell/Arm/Shell.efi differ
-- 
1.9.1

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


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

2015-08-19 Thread Ard Biesheuvel
On 19 August 2015 at 09:53, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 22:29, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


 I had mistakenly omitted the -ffunction-sections -fdata-sections
 switches, but adding those makes it even worse

   the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

 so there is definitely something dodgy going on here.


 I managed to make this work by also adding the
 -fno-asynchronous-unwind-tables option. It appears that
 (unsurprisingly) the unwinding info is preventing code from being
 pruned.

 So with  -Os -ffunction-sections -fdata-sections
 -fno-asynchronous-unwind-tables, we get even better results than
 GCC49, since we can actually turn on size optimization for MinGW.
 On GCC49, we can only enable optimization if we also enable
 -maccumulate-outgoing-args, which -according to the man page- results
 in a notable increase in code size. (I assume this is the reason we
 don't optimize the GCC49 X64 builds at all)

 If I just look at VolInfo of the FVMAIN_COMPACT.Fv generated by each
 build (UNIXGCC with mingw 4.9 vs GCC49), I get 767 KB for MinGW for
 the file length of the first embedded FV, where GCC49 takes up 794 KB.
 Maybe not spectacular, but more than significant.

As it turns out, the -mcmodel=large we use for GCC4x/X64 is causing
much of the bloat here. If I remove it, the GCC49 build shrinks to 751
KB (Again, the size of the first FV. Note that this is compressed
size, but it is relevant nonetheless)

Does anyone remember why we use that? My build runs fine without it
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


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

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
it does make some difference, it is still not sufficient

Building OvmfX64 in RELEASE mode gives me

Before:
  the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

After:
  the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

where GCC/ELF obviously produces something  0xcc000

I will report back to Nick tomorrow.

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


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

2015-08-19 Thread Ard Biesheuvel
On 19 August 2015 at 12:47, Leif Lindholm leif.lindh...@linaro.org wrote:
 On Wed, Aug 19, 2015 at 11:51:46AM +0200, Ard Biesheuvel wrote:
 No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
 only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
 r11298 (2011-02-03) so it may well be broken. So remove it.

 48h have passed.
 Reviewed-by: Leif Lindholm leif.lindh...@linaro.org


Thanks
Committed as SVN r18237

-- 
Ard.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
 v2: remove more outdated '#ifdef ARM_CPU_ARMv6' from ArmLib

  ArmPkg/ArmPkg.dsc  |   4 -
  ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c |  37 ---
  ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf |  32 ---
  ArmPkg/Include/Library/ArmLib.h|   6 +-
  ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c |  49 
  ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf   |  50 
  ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c  | 135 --
  ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf  |  50 
  ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf|  46 
  ArmPkg/Library/ArmLib/Arm11/Arm11Support.S | 257 
 
  ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm   | 157 
 
  ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S   |   6 -
  ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm |   6 -
  13 files changed, 1 insertion(+), 834 deletions(-)

 diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
 index 10e8a1a83d46..1237eed65953 100644
 --- a/ArmPkg/ArmPkg.dsc
 +++ b/ArmPkg/ArmPkg.dsc
 @@ -152,10 +152,6 @@ [Components.ARM]
ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Lib.inf
ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf

 -#  ArmPkg/Library/ArmLib/Arm11/Arm11ArmLib.inf
 -#  ArmPkg/Library/ArmLib/Arm11/Arm11ArmLibPrePi.inf
 -#  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
 -#  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf

 diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c 
 b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
 deleted file mode 100644
 index a08b7b1aee3f..
 --- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
 +++ /dev/null
 @@ -1,37 +0,0 @@
 -/** @file
 -
 -  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
 -
 -  This program and the accompanying materials
 -  are licensed and made available under the terms and conditions of the BSD 
 License
 -  which accompanies this distribution.  The full text of the license may be 
 found at
 -  http://opensource.org/licenses/bsd-license.php
 -
 -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
 -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
 -
 -**/
 -
 -#include Base.h
 -#include Library/ArmLib.h
 -#include Library/ArmCpuLib.h
 -#include Library/IoLib.h
 -#include Library/PcdLib.h
 -
 -VOID
 -ArmCpuSetup (
 -  IN  UINTN MpId
 -  )
 -{
 -  ASSERT(0); //TODO: Implement me
 -}
 -
 -
 -VOID
 -ArmCpuSetupSmpNonSecure (
 -  IN  UINTN MpId
 -  )
 -{
 -  ASSERT(0); //TODO: Implement me
 -}
 -
 diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf 
 b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
 deleted file mode 100644
 index 3a796c19d0cc..
 --- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
 +++ /dev/null
 @@ -1,32 +0,0 @@
 -#/* @file
 -#  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
 -#
 -#  This program and the accompanying materials
 -#  are licensed and made available under the terms and conditions of the 
 BSD License
 -#  which accompanies this distribution.  The full text of the license may 
 be found at
 -#  http://opensource.org/licenses/bsd-license.php
 -#
 -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
 -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
 -#
 -#*/
 -
 -[Defines]
 -  INF_VERSION= 0x00010005
 -  BASE_NAME  = Arm11MpCoreLib
 -  FILE_GUID  = dc8a69e0-6be0-469c-94d3-5e6d71aa9808
 -  MODULE_TYPE= BASE
 -  VERSION_STRING = 1.0
 -  LIBRARY_CLASS  = ArmCpuLib
 -
 -[Packages]
 -  MdePkg/MdePkg.dec
 -  ArmPkg/ArmPkg.dec
 -
 -[LibraryClasses]
 -  ArmLib
 -  IoLib
 -  PcdLib
 -
 -[Sources.common]
 -  Arm11Lib.c
 diff --git a/ArmPkg/Include/Library/ArmLib.h 
 b/ArmPkg/Include/Library/ArmLib.h
 index 9effb3eea9bf..c83a5a7f1b3c 100644
 --- a/ArmPkg/Include/Library/ArmLib.h
 +++ b/ArmPkg/Include/Library/ArmLib.h
 @@ -19,11 +19,7 @@
  #include Uefi/UefiBaseType.h

  #ifdef MDE_CPU_ARM
 -  #ifdef

Re: [edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 11:04, Haojian Zhuang haojian.zhu...@linaro.org wrote:
 Support multiple PL061 controllers.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
 ---
  ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 
 ++---
  .../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
  ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
  3 files changed, 96 insertions(+), 54 deletions(-)

 diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
 b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
 index e8a2094..3027656 100644
 --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
 +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
 @@ -28,6 +28,7 @@
  #include Drivers/PL061Gpio.h

  BOOLEAN mPL061Initialized = FALSE;
 +PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;

  /**
Function implementations
 @@ -38,20 +39,31 @@ PL061Identify (
VOID
)
  {
 -  // Check if this is a PrimeCell Peripheral
 -  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
 -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
 -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
 -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
 -return EFI_NOT_FOUND;
 +  UINTNIndex;
 +  UINT32   RegisterBase;

Why is this a 32-bit value?

 +
 +  if (   (mPL061PlatformGpio-GpioCount == 0)
 +  || (mPL061PlatformGpio-GpioControllerCount == 0)) {
 + return EFI_NOT_FOUND;
}

 -  // Check if this PrimeCell Peripheral is the PL061 GPIO
 -  if ((MmioRead8 (PL061_GPIO_PERIPH_ID0) != 0x61)
 -  ||  (MmioRead8 (PL061_GPIO_PERIPH_ID1) != 0x10)
 -  ||  ((MmioRead8 (PL061_GPIO_PERIPH_ID2)  0xF) != 0x04)
 -  ||  (MmioRead8 (PL061_GPIO_PERIPH_ID3) != 0x00)) {
 -return EFI_NOT_FOUND;
 +  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; Index++) {
 +RegisterBase = (UINT32) 
 mPL061PlatformGpio-GpioController[Index].RegisterBase;
 +// Check if this is a PrimeCell Peripheral
 +if ((MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID0) != 0x0D)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID1) != 0xF0)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID2) != 0x05)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID3) != 0xB1)) {
 +  return EFI_NOT_FOUND;
 +}
 +
 +// Check if this PrimeCell Peripheral is the PL061 GPIO
 +if ((MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID0) != 0x61)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID1) != 0x10)
 +||  ((MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID2)  0xF) != 
 0x04)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID3) != 0x00)) {
 +  return EFI_NOT_FOUND;
 +}
}

return EFI_SUCCESS;
 @@ -84,6 +96,30 @@ PL061Initialize (
return Status;
  }

 +EFI_STATUS
 +EFIAPI
 +PL061Locate (
 +  IN  EMBEDDED_GPIO_PIN Gpio,
 +  OUT UINT32*ControllerIndex,
 +  OUT UINT32*ControllerOffset,
 +  OUT UINT32*RegisterBase
 +  )
 +{
 +  UINT32Index;
 +
 +  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; Index++) {
 +if ((Gpio = mPL061PlatformGpio-GpioController[Index].GpioIndex)
 +  (Gpio  mPL061PlatformGpio-GpioController[Index].GpioIndex
 + + mPL061PlatformGpio-GpioController[Index].InternalGpioCount)) 
 {
 +  *ControllerIndex = Index;
 +  *ControllerOffset = Gpio % 
 mPL061PlatformGpio-GpioController[Index].InternalGpioCount;

Since you are relying on the internal GPIO count to be the same for
all instances, you should probably check that the value is correct in
PL061Identify()

 +  *RegisterBase = mPL061PlatformGpio-GpioController[Index].RegisterBase;
 +  return EFI_SUCCESS;
 +}
 +  }
 +  return EFI_INVALID_PARAMETER;
 +}
 +
  /**

  Routine Description:
 @@ -110,11 +146,15 @@ Get (
)
  {
EFI_STATUSStatus = EFI_SUCCESS;
 +  UINT32Index, Offset, RegisterBase;

 -  if ((Value == NULL)
 -  ||  (Gpio  LAST_GPIO_PIN))
 -  {
 -return EFI_INVALID_PARAMETER;
 +  Status = PL061Locate (Gpio, Index, Offset, RegisterBase);
 +  if (EFI_ERROR (Status))
 +goto EXIT;
 +
 +  if (Value == NULL) {
 +Status = EFI_INVALID_PARAMETER;
 +goto EXIT;
}

// Initialize the hardware if not already done
 @@ -125,7 +165,7 @@ Get (
  }
}

 -  if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Gpio)  2))) {
 +  if (MmioRead8 (RegisterBase + PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Offset) 
  2))) {
  *Value = 1;
} else {
  *Value = 0;
 @@ -162,12 +202,11 @@ Set (
)
  {
EFI_STATUSStatus = EFI_SUCCESS;
 +  UINT32Index, Offset, RegisterBase;

 -  // Check for errors
 -  if (Gpio  LAST_GPIO_PIN) {
 -Status = EFI_INVALID_PARAMETER;
 +  Status = PL061Locate (Gpio, Index, Offset, RegisterBase);
 +  if (EFI_ERROR (Status))
  goto EXIT;
 -  }

// Initialize the hardware if not already 

Re: [edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 11:31, Haojian Zhuang haojian.zhu...@linaro.org wrote:
 On Tue, 2015-08-18 at 11:22 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 11:04, Haojian Zhuang haojian.zhu...@linaro.org wrote:
  Support multiple PL061 controllers.
 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
  ---
   ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 
  ++---
   .../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
   ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
   3 files changed, 96 insertions(+), 54 deletions(-)
 
  diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
  b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  index e8a2094..3027656 100644
  --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  @@ -28,6 +28,7 @@
   #include Drivers/PL061Gpio.h
 
   BOOLEAN mPL061Initialized = FALSE;
  +PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;
 
   /**
 Function implementations
  @@ -38,20 +39,31 @@ PL061Identify (
 VOID
 )
   {
  -  // Check if this is a PrimeCell Peripheral
  -  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
  -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
  -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
  -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
  -return EFI_NOT_FOUND;
  +  UINTNIndex;
  +  UINT32   RegisterBase;

 Why is this a 32-bit value?

 All registers in PL061 are 32-bit. So we don't need to define UINTN at
 here.


So what happens if the GPIO controller is mapped above 4 GB in physical memory?

  +EFI_STATUS
  +EFIAPI
  +PL061Locate (
  +  IN  EMBEDDED_GPIO_PIN Gpio,
  +  OUT UINT32*ControllerIndex,
  +  OUT UINT32*ControllerOffset,
  +  OUT UINT32*RegisterBase
  +  )
  +{
  +  UINT32Index;
  +
  +  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; 
  Index++) {
  +if ((Gpio = mPL061PlatformGpio-GpioController[Index].GpioIndex)
  +  (Gpio  mPL061PlatformGpio-GpioController[Index].GpioIndex
  + + 
  mPL061PlatformGpio-GpioController[Index].InternalGpioCount)) {
  +  *ControllerIndex = Index;
  +  *ControllerOffset = Gpio % 
  mPL061PlatformGpio-GpioController[Index].InternalGpioCount;

 Since you are relying on the internal GPIO count to be the same for
 all instances, you should probably check that the value is correct in
 PL061Identify()

 OK. I'll check whether it's 8 at here.

  @@ -329,6 +367,9 @@ PL061InstallProtocol (
 //
 ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, gEmbeddedGpioProtocolGuid);
 
  +  Status = gBS-LocateProtocol (gPlatformGpioProtocolGuid, NULL, (VOID 
  **)mPL061PlatformGpio);
  +  ASSERT_EFI_ERROR (Status);
  +

 We should fall back to using the PCD if the protocol cannot be found.
 This way, we won't break existing users.


 I was intended to use fallback. But I think it's not good enough.

 1. If anyone defines the PCD register base in dec file. The fallback
 mechanism will be broken.


Well, you would only look at the PCD if the protocol is not installed,
so I don't see how that would change anything compared to the current
situation.

 2. Since every driver is built as module, we must create the driver
 dependency.


Please try and use a BEFORE ... depex instead, you can put it in your
platform GPIO DXE with the file GUID of the PL061 DXE driver.

 // Install the Embedded GPIO Protocol onto a new handle
 Handle = NULL;
 Status = gBS-InstallMultipleProtocolInterfaces(
  diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf 
  b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf
  index 9d9e4cd..971452c 100644
  --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf
  +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf
  @@ -45,6 +45,7 @@
 
   [Protocols]
 gEmbeddedGpioProtocolGuid
  +  gPlatformGpioProtocolGuid
 
   [Depex]
  -  TRUE
  +  gPlatformGpioProtocolGuid

 Likewise, this breaks existing users

 Withouth this dependency, LocateProtocol() will be invoked before
 InstallMultipleProtocols(). So I have to add the dependency at here.


Where is the InstallMultipleProtocols() call? Are you going to post it as well?

 I can't find that any driver is using PL061 in edk2 code repository. So
 I can't update the code to reference PL061 driver.


Well, that is not entirely the point. First of all, it may be used
outside of the edk2 tree. But we should also not complicate the common
case by forcing everyone to use the multiple GPIO protocol and install
it programmatically rather than simply setting a PCD

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


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

2015-08-24 Thread Ard Biesheuvel
On 24 August 2015 at 19:20, Bill Paul wp...@windriver.com wrote:
 Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to
 walk into mine at 10:06:10 on Monday 24 August 2015 and say:

 On 24 August 2015 at 19:02, Bill Paul wp...@windriver.com wrote:
  Of all the gin joints in all the towns in all the world, Ard Biesheuvel
  had to
 
  walk into mine at 09:54:08 on Monday 24 August 2015 and say:
[...]
  Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
  iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
  we have a LLP64 environment for X64 available to those without the
  possibility or the desire to run a MS toolchains under Windows.
 
  People should be able to build a known-good crossbuild toolchain. This is
  the simplest way to provide that option.

 Meh. The primary audience of this feature are people building UEFI for
 X64 on X64, in which case the GCC4x options are arguably simpler. But
 apparently we agree that we should keep it /and/ support it.

  By the way, do you think I can get you to update the mingw-gcc-build.py
  script while you're at it? :)

 I proposed some updates here
 http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
 (with you on cc). Care to ack those?

 Is there a particular reason why you chose to use binutils from www.kernel.org
 rather than from ftpmirror.gnu.org (other than that's what it was doing
 before)?

Nope, that was it :-)

In fact, I vaguely remember noticing the kernel.org URL and thinking
hmm that's odd but for some reason, it did not provoke any action on
my part

 In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
 thought it made more sense to get both packages from the same place.

 source_files_common = {
 'binutils': {
 'url': 'http://ftpmirror.gnu.org/binutils/' + \
'binutils-$version.tar.bz2',
 'version': '2.25',
 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
 },
 }


Yes, 2.25 would be even better. In fact, it might make sense to wait
for 2.26 to appear, since it adds support for --gc-sections (see the
other part of this thread) which brings performance of mingw in line
with ELF based GCC regarding code size.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


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

2015-08-24 Thread Ard Biesheuvel
On 19 August 2015 at 00:27, Laszlo Ersek ler...@redhat.com wrote:
 On 08/18/15 22:04, Paolo Bonzini wrote:


 On 18/08/2015 08:52, Ard Biesheuvel wrote:
 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)

 Well, perhaps he can chime in and explain his motivation behind this?
 At some point, we need to start removing things, surely. Larry just
 has a higher tolerance for pain :-)

 RHEL 6 is shipping GCC 4.4.  True, there are software collections to
 overcome that, but I think supporting GCC 4.4 is a good idea for at
 least a couple more years.

 Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?

 My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
 need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays
 practically never, thankfully.

 In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
 the RHEL-6 components lack support for the pflash-backed varstore.
 Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too.

 I have a number of Fedora virtual machines just for build-testing with
 gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
 support, not the reason for it. :)

 So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms,
 gcc-4.4 corresponds to fc13.)


OK, so [supposedly] Larry is the only one who objects to deprecating
toolchains, but since he has not responded to the suggestion, I think
we should proceed anyway.

I will respin this series, and instead of bringing CYGGCC and ELFGCC
etc in line, I will propose to move them to tools_def.attic or
whichever name is preferred by the group.

Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
we have a LLP64 environment for X64 available to those without the
possibility or the desire to run a MS toolchains under Windows.

GCC44 could perhaps be moved to the attic as well, but it does not
need to be in this series imo

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


[edk2] [PATCH v2 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
Instead of omitting some drivers that are known to break the Foundation
model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
simply fail to load without interfering with the boot.

Changes since v1:
- Print a diagnostic at EFI_D_WARN level that we are about to access the
  PrimeCell ID registers. This is currently not required, since the Foundation
  model deals gracefully with the reads to the unpopulated range, but this may
  change in future versions
- Added Leif's R-b
- Rebased onto latest upstream

Ard Biesheuvel (3):
  ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
  ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
initializing
  ArmPlatformPkg/FVP: unify support for Foundation and Base models

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 22 

 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 16 
++
 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
+++
 ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 

 8 files changed, 70 insertions(+), 18 deletions(-)

-- 
1.9.1

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


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 15:50, Leif Lindholm leif.lindh...@linaro.org wrote:
 On Tue, Aug 18, 2015 at 02:14:53PM +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 14:12, Leif Lindholm leif.lindh...@linaro.org wrote:
  On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
  On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org 
  wrote:
   Instead of omitting some drivers that are known to break the Foundation
   model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
   simply fail to load without interfering with the boot.
  
   This way, we can use the same boot image for both models.
  
 
  Ping?
 
  Basicallt looks good to me, but I thought I'd wait for Ryan to comment
  (and he's on holiday through this week).
 
  Just to confirm - the Mmio probes just return zeroes in the Foundation
  model, rather than aborting?
 

 Foundation model output:

 WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c050fe0.
 WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c1f0fe0.

 Note sure what these reads return, but in each case, the first byte
 already differs from the expected value so the init aborts.

 I know that this would still be sufficient to blow up on a real
 system, but thankfully the model does not model /that/ :-)

 No, my main concern would be if future versions of the model delete
 this trapping and instead signal an abort (or do something else
 entirely), to better mimic hardware behaviour.

 Do we have output console available at this point?
 If so, maybe put in a printout - at least in DEBUG build - that this
 is about to happen, to reduce debug time if the model behaviour
 changes?


I suppose that makes sense. These are DXEs being launched, so it is
definitely feasible to print some diagnostic on a DEBUG build.

 Regardless, unless Ryan objects on Monday:
 Reviewed-by: Leif Lindholm leif.lindh...@linaro.org


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


[edk2] [PATCH v2 1/3] ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing

2015-08-18 Thread Ard Biesheuvel
To deal gracefully with the absence of the PL180 hardware on
the Foundation model, check the PrimeCell ID before proceeding
with the installation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c | 16 
 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h | 17 +
 2 files changed, 33 insertions(+)

diff --git a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c 
b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
index 411a61ed040f..688cd8a98ced 100644
--- a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
+++ b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
@@ -521,6 +521,22 @@ PL180MciDxeInitialize (
   EFI_STATUSStatus;
   EFI_HANDLEHandle;
 
+  DEBUG ((EFI_D_WARN, Probing ID registers at 0x%lx for a PL180\n,
+MCI_PERIPH_ID_REG0));
+
+  // Check if this is a PL180
+  if (MmioRead8 (MCI_PERIPH_ID_REG0) != MCI_PERIPH_ID0 ||
+  MmioRead8 (MCI_PERIPH_ID_REG1) != MCI_PERIPH_ID1 ||
+  MmioRead8 (MCI_PERIPH_ID_REG2) != MCI_PERIPH_ID2 ||
+  MmioRead8 (MCI_PERIPH_ID_REG3) != MCI_PERIPH_ID3 ||
+  MmioRead8 (MCI_PCELL_ID_REG0)  != MCI_PCELL_ID0  ||
+  MmioRead8 (MCI_PCELL_ID_REG1)  != MCI_PCELL_ID1  ||
+  MmioRead8 (MCI_PCELL_ID_REG2)  != MCI_PCELL_ID2  ||
+  MmioRead8 (MCI_PCELL_ID_REG3)  != MCI_PCELL_ID3) {
+
+return EFI_NOT_FOUND;
+  }
+
   Handle = NULL;
 
   MCI_TRACE (PL180MciDxeInitialize());
diff --git a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h 
b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h
index 6dc155ee9a61..ce38a9e70619 100644
--- a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h
+++ b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h
@@ -51,6 +51,23 @@
 #define MCI_SELECT_REG  (MCI_SYSCTL + 0x044)
 #define MCI_FIFOCOUNT_REG   (MCI_SYSCTL + 0x048)
 #define MCI_FIFO_REG(MCI_SYSCTL + 0x080)
+#define MCI_PERIPH_ID_REG0  (MCI_SYSCTL + 0xFE0)
+#define MCI_PERIPH_ID_REG1  (MCI_SYSCTL + 0xFE4)
+#define MCI_PERIPH_ID_REG2  (MCI_SYSCTL + 0xFE8)
+#define MCI_PERIPH_ID_REG3  (MCI_SYSCTL + 0xFEC)
+#define MCI_PCELL_ID_REG0   (MCI_SYSCTL + 0xFF0)
+#define MCI_PCELL_ID_REG1   (MCI_SYSCTL + 0xFF4)
+#define MCI_PCELL_ID_REG2   (MCI_SYSCTL + 0xFF8)
+#define MCI_PCELL_ID_REG3   (MCI_SYSCTL + 0xFFC)
+
+#define MCI_PERIPH_ID0  0x80
+#define MCI_PERIPH_ID1  0x11
+#define MCI_PERIPH_ID2  0x04
+#define MCI_PERIPH_ID3  0x00
+#define MCI_PCELL_ID0   0x0D
+#define MCI_PCELL_ID1   0xF0
+#define MCI_PCELL_ID2   0x05
+#define MCI_PCELL_ID3   0xB1
 
 #define MCI_POWER_OFF   0
 #define MCI_POWER_UPBIT1
-- 
1.9.1

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


[edk2] [PATCH v2 3/3] ArmPlatformPkg/FVP: unify support for Foundation and Base models

2015-08-18 Thread Ard Biesheuvel
Now that the PL180 and PL111 drivers know how to behave when executed
on the Foundation model that does not emulate the hardware, we can
remove the ARM_FOUNDATION_FVP ifdefs and produce a single build that
runs on both the Foundation model and the Base model.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 13 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf |  4 
 2 files changed, 17 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 119ba3a0c61e..28fc1d85243d 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -41,9 +41,7 @@ [LibraryClasses.common]
 
   
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
   
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-!ifndef ARM_FOUNDATION_FVP
   
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-!endif
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
@@ -85,14 +83,9 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Fixed Virtual Platform
   gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|ARM-FVP
 
-!ifndef ARM_FOUNDATION_FVP
   # Up to 8 cores on Base models. This works fine if model happens to have 
less.
   gArmPlatformTokenSpaceGuid.PcdCoreCount|8
   gArmPlatformTokenSpaceGuid.PcdClusterCount|2
-!else
-  # Up to 4 cores on Foundation models. This works fine if model happens to 
have less.
-  gArmPlatformTokenSpaceGuid.PcdCoreCount|4
-!endif
 
   #
   # NV Storage PCDs. Use base of 0x0C00 for NOR1
@@ -149,14 +142,12 @@ [PcdsFixedAtBuild.common]
   ## PL031 RealTimeClock
   gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17
 
-!ifndef ARM_FOUNDATION_FVP
   ## PL111 Versatile Express Motherboard controller
   gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x1C1F
 
   ## PL180 MMC/SD card controller
   gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x1C010048
   gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x1C05
-!endif
 
   #
   # ARM General Interrupt Controller
@@ -280,9 +271,7 @@ [Components.common]
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-!ifndef ARM_FOUNDATION_FVP
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
-!endif
   ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
   #
@@ -290,13 +279,11 @@ [Components.common]
   #
   ArmPkg/Filesystem/SemihostFs/SemihostFs.inf
 
-!ifndef ARM_FOUNDATION_FVP
   #
   # Multimedia Card Interface
   #
   EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe.inf
-!endif
 
   #
   # Platform Driver
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
index 9c447084e316..1d92d6f34832 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
@@ -160,9 +160,7 @@ [FV.FvMain]
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-!ifndef ARM_FOUNDATION_FVP
   INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
-!endif
   INF ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
   #
@@ -178,13 +176,11 @@ [FV.FvMain]
   INF FatBinPkg/EnhancedFatDxe/Fat.inf
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
-!ifndef ARM_FOUNDATION_FVP
   #
   # Multimedia Card Interface
   #
   INF EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf
   INF ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe.inf
-!endif
 
   #
   # Platform Driver
-- 
1.9.1

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


[edk2] [PATCH v2 2/3] ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before initializing

2015-08-18 Thread Ard Biesheuvel
To deal gracefully with the absence of the PL111 hardware on
the Foundation model, check the PrimeCell ID before proceeding
with the installation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 22 

 ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 

 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
index cbc20343496b..b721061fc1df 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
@@ -156,6 +156,11 @@ LcdGraphicsOutputDxeInitialize (
   EFI_STATUS  Status = EFI_SUCCESS;
   LCD_INSTANCE* Instance;
 
+  Status = LcdIdentify ();
+  if (EFI_ERROR(Status)) {
+goto EXIT;
+  }
+
   Status = LcdInstanceContructor (Instance);
   if (EFI_ERROR(Status)) {
 goto EXIT;
diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
index dfbf2ed67122..8856b79901b6 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
@@ -106,7 +106,7 @@ InitializeDisplay (
 );
 
 EFI_STATUS
-LcdIndentify (
+LcdIdentify (
   VOID
 );
 
diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
index ad841cd8dcac..b5e113b844d4 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
@@ -27,6 +27,28 @@
  **/
 
 EFI_STATUS
+LcdIdentify (
+  VOID
+  )
+{
+  DEBUG ((EFI_D_WARN, Probing ID registers at 0x%lx for a PL111\n,
+PL111_REG_CLCD_PERIPH_ID_0));
+
+  // Check if this is a PL111
+  if (MmioRead8 (PL111_REG_CLCD_PERIPH_ID_0) == PL111_CLCD_PERIPH_ID_0 
+  MmioRead8 (PL111_REG_CLCD_PERIPH_ID_1) == PL111_CLCD_PERIPH_ID_1 
+ (MmioRead8 (PL111_REG_CLCD_PERIPH_ID_2)  0xf) == PL111_CLCD_PERIPH_ID_2 

+  MmioRead8 (PL111_REG_CLCD_PERIPH_ID_3) == PL111_CLCD_PERIPH_ID_3 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_0) == PL111_CLCD_P_CELL_ID_0 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_1) == PL111_CLCD_P_CELL_ID_1 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_2) == PL111_CLCD_P_CELL_ID_2 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_3) == PL111_CLCD_P_CELL_ID_3) {
+return EFI_SUCCESS;
+  }
+  return EFI_NOT_FOUND;
+}
+
+EFI_STATUS
 LcdInitialize (
   IN EFI_PHYSICAL_ADDRESS   VramBaseAddress
   )
diff --git a/ArmPlatformPkg/Include/Drivers/PL111Lcd.h 
b/ArmPlatformPkg/Include/Drivers/PL111Lcd.h
index 8c1c29de6cdd..18e28af805f6 100644
--- a/ArmPlatformPkg/Include/Drivers/PL111Lcd.h
+++ b/ArmPlatformPkg/Include/Drivers/PL111Lcd.h
@@ -47,6 +47,15 @@
 #define PL111_REG_CLCD_P_CELL_ID_2((UINTN)PcdGet32 (PcdPL111LcdBase) + 
0xFF8)
 #define PL111_REG_CLCD_P_CELL_ID_3((UINTN)PcdGet32 (PcdPL111LcdBase) + 
0xFFC)
 
+#define PL111_CLCD_PERIPH_ID_00x11
+#define PL111_CLCD_PERIPH_ID_10x11
+#define PL111_CLCD_PERIPH_ID_20x04
+#define PL111_CLCD_PERIPH_ID_30x00
+#define PL111_CLCD_P_CELL_ID_00x0D
+#define PL111_CLCD_P_CELL_ID_10xF0
+#define PL111_CLCD_P_CELL_ID_20x05
+#define PL111_CLCD_P_CELL_ID_30xB1
+
 /**/
 
 // Register components (register bits)
-- 
1.9.1

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


[edk2] [PATCH v2 1/2] ShellPkg: force use of AARCH64 small model when building DEBUG shell

2015-08-19 Thread Ard Biesheuvel
The tiny code model used by AARCH64 only supports binaries of up to
1 MB in size. Since the Shell application exceeds that when built in
DEBUG mode, make sure we build it using the small code model instead.

Cc: Jaben Carsey jaben.car...@intel.com,
Cc: Shumin Qiu shumin@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 ShellPkg/Application/Shell/Shell.inf | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ShellPkg/Application/Shell/Shell.inf 
b/ShellPkg/Application/Shell/Shell.inf
index f7039369227c..09aecf717bd7 100644
--- a/ShellPkg/Application/Shell/Shell.inf
+++ b/ShellPkg/Application/Shell/Shell.inf
@@ -108,3 +108,9 @@ [Pcd]
   gEfiShellPkgTokenSpaceGuid.PcdShellForceConsole ## CONSUMES
   gEfiShellPkgTokenSpaceGuid.PcdShellSupplier ## CONSUMES
 
+[BuildOptions.AARCH64]
+  # The tiny code model used by AARCH64 only supports binaries of up to 1 MB in
+  # size. Since the Shell application exceeds that when built in DEBUG mode,
+  # make sure we build it using the small code model instead.
+  GCC:DEBUG_*_*_CC_FLAGS = -mcmodel=small
+  GCC:DEBUG_*_*_DLINK_FLAGS = -z common-page-size=0x1000
-- 
1.9.1

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


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

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


I had mistakenly omitted the -ffunction-sections -fdata-sections
switches, but adding those makes it even worse

  the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

so there is definitely something dodgy going on here.

I may not have the bandwidth to investigate this in depth, though.

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


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

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
  On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
  MinGW generates PE/COFF not ELF, so much of the linker command line is
  different, and it really deserves a toolchain of its own
 
  Why does it deserve a toolchain of its own if the other toolchain
  produces better code? Why should EDK II care about using the different
  linker path if it isn't the best recommended way to build images?
 

 By the same logic, why on earth do we insist on retaining support for
 GCC44 and GCC45?

 Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
 same ball park size-wise. UNIXGCC produced much larger images because
 it could not strip unused functions/data.


Yeah, that is still true, unfortunately. Having a LLP64 toolchain
under Linux is nice, though, if only for test coverage

 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)


Well, perhaps he can chime in and explain his motivation behind this?
At some point, we need to start removing things, surely. Larry just
has a higher tolerance for pain :-)

 Note that it is not about the linker path, but about the options that
 we pass, for instance to get 4 KB section alignment. MinGW does not
 need a linker script for this, you can simply set --section-alignment
 and --file-alignment on the command line.

 As for the PE/COFF support: if you are incorporating PE/COFF binary
 static libraries into your build, you need a native PE/COFF toolchain.

 Is this something we want to support?


Perhaps not

 But in general, I think the ELF to PE/COFF conversion is not the most
 elegant step in the build, and I would prefer to avoid it if possible
 (only, there is no PE/COFF support in the GNU tools for ARM or
 AARCH64)

 It is doing a better job than any other GCC based option we have.

 Certainly LTO will be a big change for our GCC based builds. If
 somehow LTO support is finally integrated into EDK II and manages to
 directly produce a PE/COFF image easily on Linux, then I don't think
 ELF is needed.


Yes, that is another thing to consider.

All in all, I think we agree that it would be useful to get rid of as
much cruft as we can, and my cleanup is intended to reduce the
maintenance burden of the GCC4x series that we want to keep. I am
perfectly happy getting rid of ELFGCC, CYGGCC and even UNIXGCC if we
can come up with a reasonble replacement.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


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

2015-08-19 Thread Ard Biesheuvel
On 18 August 2015 at 22:29, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


 I had mistakenly omitted the -ffunction-sections -fdata-sections
 switches, but adding those makes it even worse

   the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

 so there is definitely something dodgy going on here.


I managed to make this work by also adding the
-fno-asynchronous-unwind-tables option. It appears that
(unsurprisingly) the unwinding info is preventing code from being
pruned.

So with  -Os -ffunction-sections -fdata-sections
-fno-asynchronous-unwind-tables, we get even better results than
GCC49, since we can actually turn on size optimization for MinGW.
On GCC49, we can only enable optimization if we also enable
-maccumulate-outgoing-args, which -according to the man page- results
in a notable increase in code size. (I assume this is the reason we
don't optimize the GCC49 X64 builds at all)

If I just look at VolInfo of the FVMAIN_COMPACT.Fv generated by each
build (UNIXGCC with mingw 4.9 vs GCC49), I get 767 KB for MinGW for
the file length of the first embedded FV, where GCC49 takes up 794 KB.
Maybe not spectacular, but more than significant.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


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

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

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

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

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

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

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

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

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

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

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

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


No, you can't really.

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

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


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

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

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

 Thanks for this much needed tool chain definition consolidation. I ran
 a build test with and without the patch. The build test uses GCC44-49
 and Microsoft tool chains. Log files are here: http://notabs.org/uefi/tmp/.


Thanks a lot for giving it a spin.

 Here is what is see in the log files with respect to the patch:
 1) GCC49 X64 and IA32
GenFw: ERROR 3000: Invalid Unsupported section alignment.

I cannot reproduce this, unfortunately. Can you please check whether
your BaseTools

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

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

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

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 10e8a1a83d46..1237eed65953 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -152,10 +152,6 @@ [Components.ARM]
   ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Lib.inf
   ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
 
-#  ArmPkg/Library/ArmLib/Arm11/Arm11ArmLib.inf
-#  ArmPkg/Library/ArmLib/Arm11/Arm11ArmLibPrePi.inf
-#  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
-#  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
   ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
   ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
 
diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c 
b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
deleted file mode 100644
index a08b7b1aee3f..
--- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/** @file
-
-  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include Base.h
-#include Library/ArmLib.h
-#include Library/ArmCpuLib.h
-#include Library/IoLib.h
-#include Library/PcdLib.h
-
-VOID
-ArmCpuSetup (
-  IN  UINTN MpId
-  )
-{
-  ASSERT(0); //TODO: Implement me
-}
-
-
-VOID
-ArmCpuSetupSmpNonSecure (
-  IN  UINTN MpId
-  )
-{
-  ASSERT(0); //TODO: Implement me
-}
-
diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf 
b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
deleted file mode 100644
index 3a796c19d0cc..
--- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
+++ /dev/null
@@ -1,32 +0,0 @@
-#/* @file
-#  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#*/
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = Arm11MpCoreLib
-  FILE_GUID  = dc8a69e0-6be0-469c-94d3-5e6d71aa9808
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = ArmCpuLib
-
-[Packages]
-  MdePkg/MdePkg.dec
-  ArmPkg/ArmPkg.dec
-
-[LibraryClasses]
-  ArmLib
-  IoLib
-  PcdLib
-
-[Sources.common]
-  Arm11Lib.c
diff --git a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c 
b/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
deleted file mode 100644
index 8c54b6cc8fd5..
--- a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/** @file
-
-  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.BR
-  Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed

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

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

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

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

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


Re: [edk2] [PATCH] ArmPkg/CpuDxe: Disable interrupt before restoring context

2015-08-24 Thread Ard Biesheuvel
On 23 August 2015 at 17:59, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 23 August 2015 at 15:39, Heyi Guo heyi@linaro.org wrote:


 On 08/17/2015 05:52 PM, Ard Biesheuvel wrote:

 On 13 August 2015 at 05:10, Heyi Guoheyi@linaro.org  wrote:

 Interrupt must be disabled before we storing ELR and other system
 registers, or else ELR will be overridden by interrupt reentrance.

 This bug is critical as we may get occasional exception or dead loop
 when interrupt reentrance occurs:

After increasing SP ... Before popping out registers
 Or
After restoring ELR

 The 1st circumstance could also be resolved by optimizing SP operation
 (Pop out registers before adding SP back), but the 2nd could not be
 resolved by disabling interrupt.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guoheyi@linaro.org
 Cc: Leif Lindholmleif.lindh...@linaro.org
 Cc: Ard Biesheuvelard.biesheu...@linaro.org
 ---
   ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S | 8 
   1 file changed, 8 insertions(+)

 diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
 b/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
 index 2682f4f..ca6c9a1 100644
 --- a/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
 +++ b/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
 @@ -358,6 +358,14 @@ ASM_PFX(AsmCommonExceptionEntry):
   #define REG_PAIR(REG1, REG2, OFFSET, CONTEXT_SIZE)ldp  REG1, REG2,
 [sp, #(OFFSET-CONTEXT_SIZE)]
   #define REG_ONE(REG1, OFFSET, CONTEXT_SIZE)   ldur REG1, [sp,
 #(OFFSET-CONTEXT_SIZE)]

 +  //
 +  // Disable interrupt(IRQ and FIQ) before restoring context,
 +  // or else the context will be corrupted by interrupt reentrance.
 +  // Interrupt mask will be restored from spsr by hardware when we call
 eret
 +  //
 +  msr   daifset, #3
 +  isb
 +

 Are you sure this is necessary? According to the ARM ARM

 
 On taking any exception to an Exception level using AArch64, all of
 PSTATE.{A, I, F} are set to 1, masking all
 interrupts that target that Exception level.
 

 Yes. However, in timer interrupt handler, we will raise TPL to HIGH_LEVEL
 and then restore TPL, while restore TPL will enable interrupt.


 Is that in the generic ARM timer code? Perhaps we should raise and
 lower the TPL in the common interrupt entry/exit path, since the
 architecture implicitly raises the TPL by entering the interrupt
 handler with interrupts disabled. In general, I don't think it is
 correct for TPL lowering code to enable interrupts if it did not find
 the enabled when it raised the TPL.

 So I think we can't avoid interrupt reentering in UEFI architecture and need
 protection when restoring interrupt context.


Yes, it seems you are right. Even though I am not happy with the idea
that we are supporting nested interrupts without exactly understanding
the implication and without there being a real need (since we use
interrupts for the timer tick only), the core does not really allow us
to change that for AARCH64 only.

So I think your patch is correct. There are still two issues to resolve, though:

1. Could you update the comment in the code to mention that interrupts
have been re-enabled by the TPL lowering code, and that we need to
disable them again only to protect the critical section that restores
the interrupted context from the stack?
2. The 32-bit ARM code appears to suffer from the same problem, so we
should fix that as well.

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


Re: [edk2] Some pages on new TianoCore wiki not being indexed (no results on Google)?

2015-08-24 Thread Ard Biesheuvel
(+ Leif)

On 24 August 2015 at 06:27, Bruce Cran br...@cran.org.uk wrote:
 It seems indexing of the new wiki at http://tianocore.org is rather poor: I
 was looking for some information about the BeagleBoard/BeagleBone,

Those instructions are slightly outdated after some recent cleanup
work (I was not aware of the existence of these pages or I would have
cleaned them up as well) We removed the build scripts since you can
now use 'build -a ARM -p BeagleBoardPkg/BeagleBoardPkg.dsc' directly.
We also removed ARMGCC and ARMLINUXGCC because GCC44 - GCC49 are
better supported, and so they should be used instead.

Also note that BeagleBoard != BeagleBone; the former is TI OMAP3 and
the latter is TI AM33xx, which is also Cortex-A8, but a completely
different SoC otherwise. We do have a port for BeagleBone Black; Leif
should be able to tell you where to find it.

-- 
Ard.



 and have found that even
 https://www.google.com/search?q=Beagle+Board+Wiki#q=tianocore+%22Beagle+Board+Wiki%22
 doesn't have any results on tianocore.org - or github.com, since the page is
 actually at
 https://github.com/tianocore/tianocore.github.io/wiki/Beagle-Board-Wiki .

 Is there a way to improve this, and also should the wiki on sourceforge.net
 be turned off to prevent confusion?

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


Re: [edk2] [PATCH v2 0/3] unify FVP Base and Foundation model support

2015-08-24 Thread Ard Biesheuvel
On 18 August 2015 at 16:10, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 Instead of omitting some drivers that are known to break the Foundation
 model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
 simply fail to load without interfering with the boot.

 Changes since v1:
 - Print a diagnostic at EFI_D_WARN level that we are about to access the
   PrimeCell ID registers. This is currently not required, since the Foundation
   model deals gracefully with the reads to the unpopulated range, but this may
   change in future versions
 - Added Leif's R-b
 - Rebased onto latest upstream


@Ryan,

Please let me know if you have any concerns regarding this series.

Thanks,
Ard.

 Ard Biesheuvel (3):
   ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
   ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
 initializing
   ArmPlatformPkg/FVP: unify support for Foundation and Base models

  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
 
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 22 
 
  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 16 
 ++
  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
 +++
  ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
 
  8 files changed, 70 insertions(+), 18 deletions(-)

 --
 1.9.1

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


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

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

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

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

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


[edk2] [PATCH v3 07/12] BaseTools/GCC: move AutoGen.obj contents to .text section

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script 
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 16cf623a3362..1f0f1afb27f4 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text : ALIGN(0x1000)
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data : ALIGN(0x1000)
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
diff --git a/BaseTools/Scripts/gcc4.4-ld-script 
b/BaseTools/Scripts/gcc4.4-ld-script
index c0aa62180440..22b3220816c9 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text ALIGN(0x20) :
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data ALIGN(0x20) :
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
diff --git a/BaseTools/Scripts/gcc4.9-ld-script 
b/BaseTools/Scripts/gcc4.9-ld-script
index 37a93cd85e94..2ac86e38fac7 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text ALIGN(0x20) :
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data ALIGN(0x40) :
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
-- 
1.9.1

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


[edk2] [PATCH v3 00/12] BaseTools: unify all GCC linker scripts

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

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

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

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

Tested with ArmVirtQemu/AARCH64 and Ovmf/X64

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

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

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

-- 
1.9.1

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

Re: [edk2] [PATCH] ArmPkg: Move FDT offset higher in RAM

2015-07-28 Thread Ard Biesheuvel
On 28 July 2015 at 11:41, Ryan Harkin ryan.har...@linaro.org wrote:


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

 On 28 July 2015 at 11:01, Ryan Harkin ryan.har...@linaro.org wrote:
  [+ Tixy as he's interested in making sure UEFI follows the Linux
  requirements]
 
  On 28 July 2015 at 07:39, Ard Biesheuvel ard.biesheu...@linaro.org
  wrote:

 
  On 27 July 2015 at 22:42, Ryan Harkin ryan.har...@linaro.org wrote:
   Device tree files in recent kernels (eg. Linux 4.2) can be 16KB.
  
   The max offset of 0x4000 meant that the device tree would be
   allocated
   at a random address, which more often than not was above the
   recommended 128MiB boundary.
  
 
  From Documentation/arm/Booting:
 
  
  4b. Setup the device tree
  ...
  A safe location is just above the 128MiB boundary from start of RAM.
  
 
  i.e., the documented protocol explicitly suggests using an address 
  128
  MB.
  So what exactly goes wrong if you load it at a random address?
 
 
  For some reason, I've been reading this as before 128MiB.  How strange
  of
  me.
 
  The advice I was following was from the bottom of the email thread where
  Nicolas Mitre says:
 
  You can therefore load everything (zImage, initrd, DTB) sequentially
  from the 32MB mark in RAM and be safe.
 
  But mostly, I was trying to keep the bottom 32MB unused.
 

 Yes, I think that is the primary requirement here.

  We don't have the option to load sequentially from 32MB unless I change
  the
  code a lot more.  I've already tried a hack that placed the 3 files
  sequentially from 0x8200 on TC2 and it works well, although it's
  technically wrong because I didn't explicity reserve memory in those
  areas
  to stop UEFI from using it.
 
  I'll try changing the max offsets to be all above 128MiB and see if it
  still
  works.  As Tixy pointed out to me, the problem I had with the Linux
  Loader's
  random address for the DTB is that it was always in the same region
  that
  Linux reserves for CMA.  And I think that starts before the DTB is
  finished
  with.
 

 I think we could simply raise your max address limit to 132 MB: by the
 looks of it, that is the maximum size the current kernel code will
 ever be able to support since it uses two adjacent sections to map the
 FDT, and sections are 2 MB at most when using long descriptors.


 I've tested it with a patch to change the max offsets to 0x8400 and it
 works well.  My hacked in debug shows:

 linux:  address 0x87FD2000
 linux:  length  0x42D248

Hmm, this doesn't look right. The zImage should be below 128 MB, since
it infers the base of DRAM by rounding down its own address to a
multiple of 128 MB.
I seem to have missed the part before where the PCD in question also
affects the placement of the zImage and not only the FDT.

 fdt:address 0x87E6E000
 fdt:length  0x3FFC
 initrd: address 0x87E73000
 initrd: length  0x15E600


So the rules say:
- zImage between 32 MB and 128 MB
- FDT preferably at the next 128 MB boundary
- initrd preferably right above the FDT

I guess your v1 was best after all: even if the FDT and initrd end up
below 128 MB, it is the best we can do with just this PCD

-- 
Ard.



 From this patch:

 diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
 index b30de91..d5b930a 100644
 --- a/ArmPkg/ArmPkg.dec
 +++ b/ArmPkg/ArmPkg.dec
 @@ -117,7 +117,7 @@
#
gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E
# The compressed Linux kernel is expected to be under 128MB from the
 beginning of the System Memory
 -
 gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F
 +
 gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0840|UINT32|0x001F^M
# Maximum file size for TFTP servers that do not support 'tsize'
 extension
gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x

 @@ -159,7 +159,7 @@
# If the fixed FDT address is not available, then it should be loaded
 below the kernel.
# The recommendation from the Linux kernel is to have the FDT below 16KB.
# (see the kernel doc: Documentation/arm/Booting)
 -  gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023
 +  gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0840|UINT32|0x0023^M
# The FDT blob must be loaded at a 64bit aligned address.
gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026


 Of course, the comments will have to change too: under 128MB = above
 128MiB and there is no recommendation for the device tree to be  16KB.

 Unless I get further comment, I'll submit a v2 patch as above with the
 comments updated.




 BTW it seems odd for the LinuxLoader - which is now a separate EFI
 application - to use fixed PCDs to parametrise its behavior. I think
 it would be justified to hardcode the recommended behavior as per the
 Linux/ARM boot protocol right into the LinuxLoader binary.

 --
 Ard.

 
 
 
  --
  Ard.
 
 
   This email thread explains that the device tree should be placed

Re: [edk2] [PATCH] ArmPkg: Move FDT offset higher in RAM

2015-07-28 Thread Ard Biesheuvel
On 28 July 2015 at 11:01, Ryan Harkin ryan.har...@linaro.org wrote:
 [+ Tixy as he's interested in making sure UEFI follows the Linux
 requirements]

 On 28 July 2015 at 07:39, Ard Biesheuvel ard.biesheu...@linaro.org wrote:

 On 27 July 2015 at 22:42, Ryan Harkin ryan.har...@linaro.org wrote:
  Device tree files in recent kernels (eg. Linux 4.2) can be 16KB.
 
  The max offset of 0x4000 meant that the device tree would be allocated
  at a random address, which more often than not was above the
  recommended 128MiB boundary.
 

 From Documentation/arm/Booting:

 
 4b. Setup the device tree
 ...
 A safe location is just above the 128MiB boundary from start of RAM.
 

 i.e., the documented protocol explicitly suggests using an address  128
 MB.
 So what exactly goes wrong if you load it at a random address?


 For some reason, I've been reading this as before 128MiB.  How strange of
 me.

 The advice I was following was from the bottom of the email thread where
 Nicolas Mitre says:

 You can therefore load everything (zImage, initrd, DTB) sequentially
 from the 32MB mark in RAM and be safe.

 But mostly, I was trying to keep the bottom 32MB unused.


Yes, I think that is the primary requirement here.

 We don't have the option to load sequentially from 32MB unless I change the
 code a lot more.  I've already tried a hack that placed the 3 files
 sequentially from 0x8200 on TC2 and it works well, although it's
 technically wrong because I didn't explicity reserve memory in those areas
 to stop UEFI from using it.

 I'll try changing the max offsets to be all above 128MiB and see if it still
 works.  As Tixy pointed out to me, the problem I had with the Linux Loader's
 random address for the DTB is that it was always in the same region that
 Linux reserves for CMA.  And I think that starts before the DTB is finished
 with.


I think we could simply raise your max address limit to 132 MB: by the
looks of it, that is the maximum size the current kernel code will
ever be able to support since it uses two adjacent sections to map the
FDT, and sections are 2 MB at most when using long descriptors.

BTW it seems odd for the LinuxLoader - which is now a separate EFI
application - to use fixed PCDs to parametrise its behavior. I think
it would be justified to hardcode the recommended behavior as per the
Linux/ARM boot protocol right into the LinuxLoader binary.

-- 
Ard.




 --
 Ard.


  This email thread explains that the device tree should be placed higher
  in RAM:
 
 
  http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187476.html
 
  It also explaines that the kernel may use memory in the 16-32KB range
  and that a zImage will by default be uncompressed to an offset of 32KB.
 
  Setting the FDT max offset at 128MiB will allow UEFI to place it higher
  up in memory, thus avoiding the problems with it being loaded to a
  random address.
 
  With this patch, by using AllocateMaxAdress, where possible the Linux
  Loader will place the FDT, initrd and kernel at the top of the 128MiB
  range, which also allows for more efficient zImage uncompression, as per
  the above thread.
 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Ryan Harkin ryan.har...@linaro.org
  ---
   ArmPkg/ArmPkg.dec | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
  index da0c8a9..67c8cc9 100644
  --- a/ArmPkg/ArmPkg.dec
  +++ b/ArmPkg/ArmPkg.dec
  @@ -158,7 +158,7 @@
 # If the fixed FDT address is not available, then it should be loaded
  below the kernel.
 # The recommendation from the Linux kernel is to have the FDT below
  16KB.
 # (see the kernel doc: Documentation/arm/Booting)
  -  gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x0023
  +
  gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x0800|UINT32|0x0023
 # The FDT blob must be loaded at a 64bit aligned address.
 gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x0026
 
  --
  2.1.0
 


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


[edk2] [PATCH v4 03/13] BaseTools IA32/X64: drop redundant alignment from linker script

2015-07-30 Thread Ard Biesheuvel
There is no need to pad out the end of a section of the start of
the following section is aligned to the same value. So drop the
redundant ALIGN() statements.

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
Tested-by: Liming Gao liming@intel.com
---
 BaseTools/Scripts/gcc-4K-align-ld-script | 3 ---
 BaseTools/Scripts/gcc4.4-ld-script   | 3 ---
 BaseTools/Scripts/gcc4.9-ld-script   | 3 ---
 3 files changed, 9 deletions(-)

diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script 
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 1f0f1afb27f4..3ed1c12fb8aa 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -7,7 +7,6 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
-. = ALIGN(0x20);
   }
   .data : ALIGN(0x1000)
   {
@@ -16,7 +15,6 @@ SECTIONS
   .bss .bss.*
   *COM*
 )
-. = ALIGN(0x20);
   }
   .eh_frame : ALIGN(0x1000)
   {
@@ -25,7 +23,6 @@ SECTIONS
   .got : ALIGN(0x1000)
   {
 *(.got .got.*)
-. = ALIGN(0x20);
   }
   .rela : ALIGN(0x1000)
   {
diff --git a/BaseTools/Scripts/gcc4.4-ld-script 
b/BaseTools/Scripts/gcc4.4-ld-script
index 22b3220816c9..0d86908d0b30 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -7,7 +7,6 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
-. = ALIGN(0x20);
   }
   .data ALIGN(0x20) :
   {
@@ -16,7 +15,6 @@ SECTIONS
   .bss .bss.*
   *COM*
 )
-. = ALIGN(0x20);
   }
   .eh_frame ALIGN(0x20) :
   {
@@ -25,7 +23,6 @@ SECTIONS
   .got ALIGN(0x20) :
   {
 *(.got .got.*)
-. = ALIGN(0x20);
   }
   .rela ALIGN(0x20) :
   {
diff --git a/BaseTools/Scripts/gcc4.9-ld-script 
b/BaseTools/Scripts/gcc4.9-ld-script
index 2ac86e38fac7..207b9e1dc7f0 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -7,7 +7,6 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 *(.rodata .rodata.* .gnu.linkonce.r.*)
-. = ALIGN(0x20);
   }
   .data ALIGN(0x40) :
   {
@@ -16,7 +15,6 @@ SECTIONS
   .bss .bss.*
   *COM*
 )
-. = ALIGN(0x20);
   }
   .eh_frame ALIGN(0x20) :
   {
@@ -25,7 +23,6 @@ SECTIONS
   .got ALIGN(0x20) :
   {
 *(.got .got.*)
-. = ALIGN(0x20);
   }
   .rela ALIGN(0x20) :
   {
-- 
1.9.1

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


[edk2] [PATCH v4 00/13] BaseTools: unify all GCC linker scripts

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

Changes since v3:
- added patch #5 which updates the various IA32/X86 linker scripts to take their
  PE/COFF header size and section alignment from the command line, before
  switching to the unified version which does the same
- added Jordan's Reviewed-by, which he gave on the condition that patch #5
  be added
- added Liming's Tested-by to the patches that apply to IA32 and X86
- added Leif's Tested-by to the patches that apply to AARCH64 (except the
  ArmVirtPkg which he didn't test, but this was my testbed during development)
  
Changes since v2:
- for easier bisection, factor out the differences between the original
  and the unified linker scripts for X86 before making the switch
  (patches #1 - #4 and #6)
- add Intel copyright notice to unified version (patch #5)
- avoid defining *_*_*_DLINK2_FLAGS so that we don't pollute the variable
  definition space of non-GCC toolchains (patches #8 and #12)
- added Laszlo's ack to patch #10

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

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

Tested with ArmVirtQemu/AARCH64 and Ovmf/X64

Branch is here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-ld-scripts-v4
(now correctly based on the GitHub repo)

Ard Biesheuvel (13):
  BaseTools IA32/X64: remove NOP padding from X86/IA32 GCC linker
scripts
  BaseTools IA32/X64: move .rodata to PE/COFF .text section
  BaseTools IA32/X64: drop redundant alignment from linker script
  BaseTools IA32/X64: move .got contents to the PE/COFF .text section
  BaseTools IA32/X64: get header size and alignment from ld commandline
  BaseTools GCC: add unified GCC linker script for all archs and
versions
  BaseTools GCC: align start of .data to .text alignment
  BaseTools GCC: move AutoGen.obj contents to .text section
  BaseTools AARCH64: move to unified GCC linker script
  ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script
  ArmVirtPkg: move to unified GCC linker script
  BaseTools AARCH64: remove incremental linker script for 64K alignment
  BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-script

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

-- 
1.9.1

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


[edk2] [PATCH v4 07/13] BaseTools GCC: align start of .data to .text alignment

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Tested-by: Liming Gao liming@intel.com
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 BaseTools/Scripts/GccBase.lds | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

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


[edk2] [PATCH v4 10/13] ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

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


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

2015-07-30 Thread Ard Biesheuvel
On 30 July 2015 at 02:59, Gao, Liming liming@intel.com wrote:
 Jordan:
   I have verified 4K aligned image build.

 Test-by: Liming Gao liming.gao@intel


Thanks Liming

Just to be clear, I assume you added something like this


diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a86a7f57143b..90dc29a5157d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -48,6 +48,9 @@ [BuildOptions]
   INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
 !endif

+[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
+  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+
 

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


when you did the test?

Thanks,
Ard.

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

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

 What about 1 more step? :)

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

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

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

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

 With that change, the series is

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

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

 -Jordan

 On 2015-07-29 08:12:02, Ard Biesheuvel wrote:
 Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use the
 new unified one instead.

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

 diff --git a/BaseTools/Conf/tools_def.template
 b/BaseTools/Conf/tools_def.template
 index d3dfdc41ada1..eeb488fb3597 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3847,10 +3847,12 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O 
 elf64-littleaarch64 -B aarch64
  DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar 
 -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections 
 -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
  DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
 -malign-double -fno-stack-protector -D EFI32
  DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
 -fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) 
 -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large
 -DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections 
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
 +DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
 common-page-size=0x20
  DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
 --entry ReferenceAcpiTable -u ReferenceAcpiTable
  DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
 --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
 $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 +DEFINE GCC44_IA32_DLINK2_FLAGS   = DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x220
  DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)  
 -melf_x86_64 --oformat=elf64-x86-64
 +DEFINE GCC44_X64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x228
  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)

  DEFINE GCC45_IA32_CC_FLAGS   = DEF(GCC44_IA32_CC_FLAGS)
 @@ -3858,7 +3860,9 @@ DEFINE GCC45_X64_CC_FLAGS= 
 DEF(GCC44_X64_CC_FLAGS)
  DEFINE GCC45_IA32_X64_DLINK_COMMON   = DEF(GCC44_IA32_X64_DLINK_COMMON)
  DEFINE GCC45_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS)
  DEFINE GCC45_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_FLAGS)
 +DEFINE GCC45_IA32_DLINK2_FLAGS   = DEF(GCC44_IA32_DLINK2_FLAGS)
  DEFINE GCC45_X64_DLINK_FLAGS = DEF(GCC44_X64_DLINK_FLAGS)
 +DEFINE GCC45_X64_DLINK2_FLAGS= DEF(GCC44_X64_DLINK2_FLAGS)
  DEFINE GCC45_ASM_FLAGS   = DEF(GCC44_ASM_FLAGS)

  DEFINE

[edk2] [PATCH v4 09/13] BaseTools AARCH64: move to unified GCC linker script

2015-07-30 Thread Ard Biesheuvel
Drop the GCC AARCH64 specific linker script and use the new
unified one instead.

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
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 BaseTools/Conf/tools_def.template   |  9 -
 BaseTools/Scripts/gcc-aarch64-ld-script | 39 
 2 files changed, 8 insertions(+), 40 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8f84b55236fd..f5e27cfc347f 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3820,10 +3820,11 @@ DEFINE GCC_IPF_CC_FLAGS= 
DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-m
 DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mword-relocations 
-mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char 
-ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb 
-mfloat-abi=soft
 DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large 
-mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
-ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
-Wno-address -fno-asynchronous-unwind-tables
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
+DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
 DEFINE GCC_IA32_X64_DLINK_COMMON   = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections
 DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u 
$(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) 
-Ttext=0x0
-DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) 
--script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-ld-script
+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)
@@ -3893,6 +3894,7 @@ DEFINE GCC47_ARM_CC_FLAGS= 
DEF(GCC46_ARM_CC_FLAGS) -mno-unaligned-ac
 DEFINE GCC47_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_AARCH64_CC_FLAGS)
 DEFINE GCC47_ARM_DLINK_FLAGS = DEF(GCC46_ARM_DLINK_FLAGS)
 DEFINE GCC47_AARCH64_DLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS)
+DEFINE GCC47_AARCH64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
--defsym=PECOFF_HEADER_SIZE=0x228
 DEFINE GCC47_ARM_ASLDLINK_FLAGS  = DEF(GCC46_ARM_ASLDLINK_FLAGS)
 DEFINE GCC47_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_ASLDLINK_FLAGS)
 
@@ -3911,6 +3913,7 @@ DEFINE GCC48_ARM_CC_FLAGS= 
DEF(GCC47_ARM_CC_FLAGS)
 DEFINE GCC48_AARCH64_CC_FLAGS= DEF(GCC47_AARCH64_CC_FLAGS)
 DEFINE GCC48_ARM_DLINK_FLAGS = DEF(GCC47_ARM_DLINK_FLAGS)
 DEFINE GCC48_AARCH64_DLINK_FLAGS = DEF(GCC47_AARCH64_DLINK_FLAGS)
+DEFINE GCC48_AARCH64_DLINK2_FLAGS= DEF(GCC47_AARCH64_DLINK2_FLAGS)
 DEFINE GCC48_ARM_ASLDLINK_FLAGS  = DEF(GCC47_ARM_ASLDLINK_FLAGS)
 DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
 
@@ -3929,6 +3932,7 @@ DEFINE GCC49_ARM_CC_FLAGS= 
DEF(GCC48_ARM_CC_FLAGS)
 DEFINE GCC49_AARCH64_CC_FLAGS= DEF(GCC48_AARCH64_CC_FLAGS)
 DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS)
 DEFINE GCC49_AARCH64_DLINK_FLAGS = DEF(GCC48_AARCH64_DLINK_FLAGS)
+DEFINE GCC49_AARCH64_DLINK2_FLAGS= DEF(GCC48_AARCH64_DLINK2_FLAGS)
 DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
 DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 
@@ -4377,6 +4381,7 @@ RELEASE_GCC47_ARM_CC_FLAGS   = 
DEF(GCC47_ARM_CC_FLAGS) -Wno-unused-but-set-v
 *_GCC47_AARCH64_ASLDLINK_FLAGS   = DEF(GCC47_AARCH64_ASLDLINK_FLAGS)
 *_GCC47_AARCH64_ASM_FLAGS= DEF(GCC47_AARCH64_ASM_FLAGS)
 *_GCC47_AARCH64_DLINK_FLAGS  = DEF(GCC47_AARCH64_DLINK_FLAGS)
+*_GCC47_AARCH64_DLINK2_FLAGS = DEF(GCC47_AARCH64_DLINK2_FLAGS)
 *_GCC47_AARCH64_PLATFORM_FLAGS   =
 *_GCC47_AARCH64_PP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_PP_FLAGS)
 *_GCC47_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS)
@@ -4502,6 +4507,7 @@ RELEASE_GCC48_ARM_CC_FLAGS   = 
DEF(GCC48_ARM_CC_FLAGS) -Wno-unused-but-set-v
 *_GCC48_AARCH64_ASLDLINK_FLAGS   = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 *_GCC48_AARCH64_ASM_FLAGS= DEF(GCC48_AARCH64_ASM_FLAGS)
 *_GCC48_AARCH64_DLINK_FLAGS  = DEF(GCC48_AARCH64_DLINK_FLAGS)
+*_GCC48_AARCH64_DLINK2_FLAGS = DEF(GCC48_AARCH64_DLINK2_FLAGS

[edk2] [PATCH v4 08/13] BaseTools GCC: move AutoGen.obj contents to .text section

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

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Tested-by: Liming Gao liming@intel.com
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 BaseTools/Scripts/GccBase.lds | 7 +++
 1 file changed, 7 insertions(+)

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

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


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

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 BaseTools/Scripts/gcc-aarch64-64K-align-ld-script | 4 
 1 file changed, 4 deletions(-)

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

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


[edk2] [PATCH v4 01/13] BaseTools IA32/X64: remove NOP padding from X86/IA32 GCC linker scripts

2015-07-30 Thread Ard Biesheuvel
The NOP padding in the GCC linker scripts ensures that all empty
regions in the ELF binary are filled with x86 NOP instructions.

There is no upside to doing this: if the CPU ends up executing these
instructions, we have little hope of resuming normal execution of the
program anyway. And having NOP slides in memory only makes it easier
for attackers to launch exploits. So remove them.

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
Tested-by: Liming Gao liming@intel.com
---
 BaseTools/Scripts/gcc4.4-ld-script | 2 +-
 BaseTools/Scripts/gcc4.9-ld-script | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Scripts/gcc4.4-ld-script 
b/BaseTools/Scripts/gcc4.4-ld-script
index 68b2767590ac..c0aa62180440 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -7,7 +7,7 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 . = ALIGN(0x20);
-  } =0x90909090
+  }
   .data ALIGN(0x20) :
   {
 *(
diff --git a/BaseTools/Scripts/gcc4.9-ld-script 
b/BaseTools/Scripts/gcc4.9-ld-script
index b69232853617..37a93cd85e94 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -7,7 +7,7 @@ SECTIONS
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
 . = ALIGN(0x20);
-  } =0x90909090
+  }
   .data ALIGN(0x40) :
   {
 *(
-- 
1.9.1

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


[edk2] [PATCH v4 02/13] BaseTools IA32/X64: move .rodata to PE/COFF .text section

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
Tested-by: Liming Gao liming@intel.com
---
 BaseTools/Scripts/gcc-4K-align-ld-script | 2 +-
 BaseTools/Scripts/gcc4.4-ld-script   | 2 +-
 BaseTools/Scripts/gcc4.9-ld-script   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script 
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 16cf623a3362..1f0f1afb27f4 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text : ALIGN(0x1000)
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data : ALIGN(0x1000)
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
diff --git a/BaseTools/Scripts/gcc4.4-ld-script 
b/BaseTools/Scripts/gcc4.4-ld-script
index c0aa62180440..22b3220816c9 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text ALIGN(0x20) :
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data ALIGN(0x20) :
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
diff --git a/BaseTools/Scripts/gcc4.9-ld-script 
b/BaseTools/Scripts/gcc4.9-ld-script
index 37a93cd85e94..2ac86e38fac7 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -6,12 +6,12 @@ SECTIONS
   .text ALIGN(0x20) :
   {
 *(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
 . = ALIGN(0x20);
   }
   .data ALIGN(0x40) :
   {
 *(
-  .rodata .rodata.* .gnu.linkonce.r.*
   .data .data.* .gnu.linkonce.d.*
   .bss .bss.*
   *COM*
-- 
1.9.1

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


[edk2] [PATCH v4 06/13] BaseTools GCC: add unified GCC linker script for all archs and versions

2015-07-30 Thread Ard Biesheuvel
This unifies all GCC linker scripts into a single parametrised GCC
linker script that can be used for all GCC versions and architectures.

The two parameters that can be set on the linker command line are:
- PECOFF_HEADER_SIZE, this is a build time property of GenFw, but
  its value is different between 32-bit and 64-bit;
- common-page-size, this can be set using -z on the ld command line,
  and controls the value of the COMMONPAGESIZE constant when used in
  a linker script. This value is used for the minimum section alignment.

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
Tested-by: Liming Gao liming@intel.com
Tested-by: Leif Lindholm leif.lindh...@linaro.org
---
 BaseTools/Scripts/GccBase.lds | 63 
 1 file changed, 63 insertions(+)

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
new file mode 100644
index ..0f0210e40703
--- /dev/null
+++ b/BaseTools/Scripts/GccBase.lds
@@ -0,0 +1,63 @@
+/** @file
+
+  Unified linker script for GCC based builds
+
+  Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.BR
+  Copyright (c) 2015, Linaro Ltd. All rights reserved.BR
+
+  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.
+
+**/
+
+SECTIONS {
+
+  /*
+   * The PE/COFF binary consists of DOS and PE/COFF headers, and a sequence of
+   * section headers adding up to PECOFF_HEADER_SIZE bytes (which differs
+   * between 32-bit and 64-bit builds). The actual start of the .text section
+   * will be rounded up based on its actual alignment.
+   */
+  . = PECOFF_HEADER_SIZE;
+
+  .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+*(.text .text.* .stub .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
+  }
+
+  /*
+   * The alignment of the .data section should be less than or equal to the
+   * alignment of the .text section. This ensures that the relative offset
+   * between these sections is the same in the ELF and the PE/COFF versions of
+   * this binary.
+   */
+  .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+*(.data .data.* .gnu.linkonce.d.*)
+*(.bss .bss.* *COM*)
+  }
+
+  .eh_frame ALIGN(CONSTANT(COMMONPAGESIZE)) : {
+KEEP (*(.eh_frame))
+  }
+
+  .rela ALIGN(CONSTANT(COMMONPAGESIZE)) : {
+*(.rela .rela.*)
+  }
+
+  /DISCARD/ : {
+*(.note.GNU-stack)
+*(.gnu_debuglink)
+*(.interp)
+*(.dynsym)
+*(.dynstr)
+*(.dynamic)
+*(.hash)
+*(.comment)
+  }
+}
-- 
1.9.1

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


[edk2] [PATCH v4 11/13] ArmVirtPkg: move to unified GCC linker script

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

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

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

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


Re: [edk2] [PATCH 1/2] ArmPkg/ArmGicLibArchLib: common check for GICv3

2015-07-31 Thread Ard Biesheuvel
On 31 July 2015 at 14:21, Ryan Harkin ryan.har...@linaro.org wrote:


 On 31 July 2015 at 13:13, Ard Biesheuvel ard.biesheu...@linaro.org wrote:

 On 31 July 2015 at 14:06, Ryan Harkin ryan.har...@linaro.org wrote:
  Make Arm and Aarch64 both use the same code, conditionally compiled, to
  check if the platform has GICv3.
 
  Both source files for Arm and Aarch64 are now identical and the next
  step is to move to a common source file.
 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Ryan Harkin ryan.har...@linaro.org
  ---
   .../Library/ArmGicArchLib/AArch64/ArmGicArchLib.c  | 26
  +++---
   ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c   | 24
  ++--
   2 files changed, 35 insertions(+), 15 deletions(-)
 
  diff --git a/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
  b/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
  index 9853c7b..b092e3a 100644
  --- a/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
  +++ b/ArmPkg/Library/ArmGicArchLib/AArch64/ArmGicArchLib.c
  @@ -15,7 +15,22 @@
   #include Library/ArmLib.h
   #include Library/ArmGicLib.h
 
  -STATIC ARM_GIC_ARCH_REVISIONmGicArchRevision;
  +STATIC ARM_GIC_ARCH_REVISIONmGicArchRevision =
  ARM_GIC_ARCH_REVISION_2;
  +
  +RETURN_STATUS
  +EFIAPI
  +ArmGicArchLibHasGicv3 (
  +  VOID
  +  )
  +{
  +#if defined (MDE_CPU_ARM)
  +  return (ArmReadIdPfr1 ()  ARM_PFR1_GIC);
  +#elif defined(MDE_CPU_AARCH64)
  +  return (ArmReadIdPfr0 ()  AARCH64_PFR0_GIC);
  +#else
  + #error Unknown chipset.
  +#endif
  +}
 

 Officially, the bit indicates whether the GIC system register
 interface is supported at the current exception level, and from that
 we infer that the system most likely has a GICv3.
 So if we don't have the SRE enabled, we try to drive it as a GICv2
 which only happens to work if this particular GICv3 has the GICv2
 compatibility mode implemented. (This is also mentioned in the
 comments)

 So the function name is a bit misleading here, although I won't insist
 that you change it.


 I'm happy to change it if you want to recommend a better name, this seems a
 but unwieldy:

 HasGicv3 - GicSystemRegistersSupported

 ... but is perhaps more correct.


Well, the function and the caller are so close together that you
shouldn't be able to miss the comment.
I do recommend STATIC for the function though.



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


 Thanks for the quick review turnaround :-)

Too quick, as it seems. Spotted an inadvertent white space change below :-)



   RETURN_STATUS
   EFIAPI
  @@ -31,7 +46,7 @@ ArmGicArchLibInitialize (
 // feature is implemented on the CPU. This is also convenient as our
  GICv3
 // driver requires SRE. If only Memory mapped access is available we
  try to
 // drive the GIC as a v2.
  -  if (ArmReadIdPfr0 ()  AARCH64_PFR0_GIC) {
  +  if (ArmGicArchLibHasGicv3()) {
   // Make sure System Register access is enabled (SRE). This depends
  on the
   // higher privilege level giving us permission, otherwise we will
  either
   // cause an exception here, or the write doesn't stick in which
  case we need
  @@ -41,18 +56,13 @@ ArmGicArchLibInitialize (
   // It is the OS responsibility to set this bit.
   IccSre = ArmGicV3GetControlSystemRegisterEnable ();
   if (!(IccSre  ICC_SRE_EL2_SRE)) {
  -  ArmGicV3SetControlSystemRegisterEnable (IccSre |
  ICC_SRE_EL2_SRE);
  +  ArmGicV3SetControlSystemRegisterEnable (IccSre| ICC_SRE_EL2_SRE);

here ^^^

 IccSre = ArmGicV3GetControlSystemRegisterEnable ();
   }
   if (IccSre  ICC_SRE_EL2_SRE) {
 mGicArchRevision = ARM_GIC_ARCH_REVISION_3;
  -  goto Done;
   }
 }
  -
  -  mGicArchRevision = ARM_GIC_ARCH_REVISION_2;
  -
  -Done:
 return RETURN_SUCCESS;
   }
 
  diff --git a/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
  b/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
  index f8822a2..b092e3a 100644
  --- a/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
  +++ b/ArmPkg/Library/ArmGicArchLib/Arm/ArmGicArchLib.c
  @@ -15,7 +15,22 @@
   #include Library/ArmLib.h
   #include Library/ArmGicLib.h
 
  -STATIC ARM_GIC_ARCH_REVISIONmGicArchRevision;
  +STATIC ARM_GIC_ARCH_REVISIONmGicArchRevision =
  ARM_GIC_ARCH_REVISION_2;
  +
  +RETURN_STATUS
  +EFIAPI
  +ArmGicArchLibHasGicv3 (
  +  VOID
  +  )
  +{
  +#if defined (MDE_CPU_ARM)
  +  return (ArmReadIdPfr1 ()  ARM_PFR1_GIC);
  +#elif defined(MDE_CPU_AARCH64)
  +  return (ArmReadIdPfr0 ()  AARCH64_PFR0_GIC);
  +#else
  + #error Unknown chipset.
  +#endif
  +}
 
   RETURN_STATUS
   EFIAPI
  @@ -31,7 +46,7 @@ ArmGicArchLibInitialize (
 // feature is implemented on the CPU. This is also convenient as our
  GICv3
 // driver requires SRE. If only Memory mapped access is available we
  try to
 // drive the GIC as a v2.
  -  if (ArmReadIdPfr1 ()  ARM_PFR1_GIC) {
  +  if (ArmGicArchLibHasGicv3()) {
   // Make sure System

[edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

2015-08-04 Thread Ard Biesheuvel
ARM BDS support in ArmVirtQemu has been broken since SVN r17969
(ArmPkg/BdsLib: Remove Linux loader from BdsLib) dated July 14th.

Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
altogether: they violate both the UEFI spec and the arm64 Linux boot
protocol, and lack the level of integration with the QEMU command
line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
Note that this supersedes 'ArmVirtPkg: align ARM BDS build with LinuxLoader
changes' that I sent out earlier today. After having discussed the matter on
IRC (#linaro-enterprise) with leiflindholm and lersek, it turns out we all
agree that the best course of action is to drop the ARM BDS entirely.

 ArmVirtPkg/ArmVirtQemu.dsc | 17 +
 ArmVirtPkg/ArmVirtQemu.fdf |  6 --
 2 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index c199cac72cfd..528d13e6aece 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,13 +57,11 @@ [LibraryClasses.common]
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 
-!if $(INTEL_BDS) == TRUE
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
   PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
-!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
@@ -128,14 +126,7 @@ [PcdsFixedAtBuild.common]
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
 
   #
-  # ARM OS Loader
-  #
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on 
virtio31:hd0:part0
-  
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 
console=ttyAMA0 earlycon uefi_debug
-
-  #
-  # Settings for ARM BDS -- use the serial console (ConIn  ConOut).
+  # Settings for BDS -- use the serial console (ConIn  ConOut).
   #
 !if $(TTY_TERMINAL) == TRUE
   
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
@@ -175,10 +166,8 @@ [PcdsFixedAtBuild.common]
   # initial location of the device tree blob passed by QEMU -- base of DRAM
   gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
 
-!if $(INTEL_BDS) == TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-!endif
 
   #
   # The maximum physical I/O addressability of the processor, set with
@@ -332,13 +321,9 @@ [Components.common]
   # Bds
   #
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-!if $(INTEL_BDS) == TRUE
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
-!else
-  ArmPlatformPkg/Bds/Bds.inf
-!endif
 
   #
   # SCSI Bus and Disk Driver
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 3c0487cd95b6..a9ad9ca6fe2d 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -171,13 +171,9 @@ [FV.FvMain]
   # Bds
   #
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-!if $(INTEL_BDS) == TRUE
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
-!else
-  INF ArmPlatformPkg/Bds/Bds.inf
-!endif
 
   #
   # Networking stack
@@ -234,14 +230,12 @@ [FV.FvMain]
   INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 
-!if $(INTEL_BDS) == TRUE
   #
   # TianoCore logo (splash screen)
   #
   FILE FREEFORM = PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
-!endif
 
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
-- 
1.9.1

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


Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

2015-08-04 Thread Ard Biesheuvel
On 4 August 2015 at 11:21, Sharma Bhupesh bhupesh.sha...@freescale.com wrote:
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Tuesday, August 04, 2015 2:36 PM
 On 08/04/15 10:38, Sharma Bhupesh wrote:
  -Original Message-
  From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
  Sent: Tuesday, August 04, 2015 2:01 PM
 
  On 4 August 2015 at 10:07, Sharma Bhupesh
  bhupesh.sha...@freescale.com
  wrote:

  With the EFI_STUB becoming more or less mandatory and the leagacy
  ARM Bds Linux Loader being deprecated, are there any plans to
  provide means
  to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
 
 
  No. FIT images are a U-Boot construct. The recommended way under UEFI
  is to install the device tree as a FDT configuration table in the
 firmware.
  Look at FdtPlatformDxe for more info. The initrd can be loaded by the
  EFI stub, by passing the initrd= option.
 
  The recommended way of doing authentication of bootable images is to
  use UEFI Secure Boot. DTB authentication is implicit if it is part of
  the UEFI image itself. How to do initrd authentication is undefined.

 (I'd say unspecified rather than undefined, but that's a side point.)

  initrd (Rootfs) is probably the easiest place to introduce a malicious
  application in, which can easily overwrite the text area, thus causing
 the core to run a Trojan.

 How is this different from overwriting applications on a normal file
 system? As far as I understand, applications are not part of the chain
 being verified.

 Cryptographically verifying the entire Root filesystem being provided with
 a software development kit, allows a OEM/customer to ensure that
 the platform only boots a application-set which is authenticated using
 their Public-Private key pairs.


Putting DTB, kernel and initrd in the same signed archive is a design
driven by convenience, not by security.

It is the firmware's responsibility to authenticate and boot the
kernel image, and provide it with a description of the hardware. The
kernel's trust of the firmware is implicit, that is why, under UEFI
Secure Boot, the only way of obtaining a DTB is from the configuration
table (the dtb= kernel command line parameter is disabled in this
case)

It is the kernel's responsibility to authenticate the file system,
regardless of whether it is a initrd or a filesystem hosted on block
storage. To the firmware, the initrd is just an opaque blob, whereas,
from the kernel pov, the initrd is a readable archive with kernel
modules and executables, each of which may have their own
authentication requirements.

 So, if the system tries to launch a rootfs which is not authenticated
 via the OEM/customer's public key, the boot process stalls and a preventive
 tamper-proofing action like zero'ing the DDR contents and reseting the SoC 
 can be taken.


A chain of trust implies discrete links. Signing everything with the
OEM/customer's public key and verifying all at the same time may be
appropriate in some cases, but you should not present it as the common
design. In general, it is much more convenient to allow the kernel to
be in charge of the public keys that authenticate subsequent boot
stages rather than mandating that DTB, kernel *and* initrd are all
signed with a public key known to the firmware.

-- 
Ard.




 Kernel modules are (and they do reside in the initrd), but they should
 already be covered by module signing.

 http://mjg59.dreamwidth.org/12368.html

 https://access.redhat.com/documentation/en-
 US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-
 signing-kernel-modules-for-secure-boot.html
 https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se
 cboot.html

 https://www.suse.com/documentation/sles-
 12/book_sle_admin/data/sec_uefi_secboot.html

 Thanks
 Laszlo

 
  The normal secure chain of boot, requires that each component verifies
  the next component it launches. FIT format seems to plug this gap.
 
  Can you point me to some documentation on UEFI secure boot and how it
  works on the
  ARM64 platforms - does it internally use and program the ARM TrustZone
  components like the TZASC and TZPC to partition the System RAM, etc
  into appropriate secure and non-secure partitions and the images
 cryptographically verify the next stage image.
  A typical flow most OEMs use is:
 
  BootROM - Arm Trusted Firmware - UEFI - Linux - Initrd
 
  The current SEC stage code for ARM64 platforms supported in EDK2 seem
  to be programming the TZASC and TZPC entities, but I cannot see any
  secure chain-of-trust being established for the next stage images
 there.
 
  Regards,
  Bhupesh
 
 
  Regards,
  Ard.
 
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
  Of Ard Biesheuvel
  Sent: Tuesday, August 04, 2015 1:27 PM
  To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
  ler...@redhat.com
  Cc: ryan.har...@linaro.org; Ard Biesheuvel
  Subject: [edk2

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

2015-08-04 Thread Ard Biesheuvel
On 4 August 2015 at 10:54, Laszlo Ersek ler...@redhat.com wrote:
 On 08/04/15 09:57, Ard Biesheuvel wrote:
 LinuxLoader has been split off from the ARM BDS into a separate
 EFI application. Because we never included this application into
 the ArmVirtPkg platforms, its ARM BDS builds have effectively been
 broken ever since that change was merged.

 Let's fix the situation by:
 - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
   have UEFI stub support enabled by default, and the LinuxLoader code for
   booting arm64 Linux kernels is buggy. Note that this does not disable
   the ARM BDS text menu, it just removes the ability to boot bare Linux
   kernels.
 - Adding the LinuxLoader EFI application to the ARM builds.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---
  ArmVirtPkg/ArmVirtQemu.dsc | 5 +
  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
  3 files changed, 14 insertions(+), 3 deletions(-)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index 2e2708d1c281..735f9edc58d6 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]

 PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf

 MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
 +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
 +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
 +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf

  [LibraryClasses.common.UEFI_DRIVER]

 ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
 @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]

gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE

 +[PcdsFeatureFlag.AARCH64]
 +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
 +
  [PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization Platform

 @@ -398,9 +404,6 @@ [Components.common]

 NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf

 NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf

 HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
 -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
 -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
 -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf

 BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index a2a82a4dba8c..92d55c770f55 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -381,3 +381,8 @@ [Components.common]
MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 +
 +[Components.ARM]
 +!if $(INTEL_BDS) == FALSE
 +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
 +!endif
 diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
 index 3c0487cd95b6..47f9b095b3af 100644
 --- a/ArmVirtPkg/ArmVirtQemu.fdf
 +++ b/ArmVirtPkg/ArmVirtQemu.fdf
 @@ -177,6 +177,9 @@ [FV.FvMain]
INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
  !else
INF ArmPlatformPkg/Bds/Bds.inf
 +!if $(ARCH) == ARM
 +  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
 +!endif
  !endif

 One question -- do we have any trick in place in ArmVirtPkg that allows
 us to find UEFI_APPLICATION modules in firmware volumes? I vaguely
 recall patches from the list that expose FVs as filesystems, or some such.

 If we use that in ArmVirtPkg, then it makes sense to build a
 UEFI_APPLICATION into the firmware binary; otherwise it doesn't. (The
 UEFI shell is located differently by the Intel BDS; the FILE_GUID of the
 shell binary is specified in PcdShellFile, and GenericBdsLib looks for
 it specifically.)

 Hm... yes, I think I have MdeModulePkg/Universal/FvSimpleFileSystemDxe
 in mind. We don't use it in ArmVirtPkg (nor OvmfPkg, FWIW). So, please
 either drop the FDF hunk, or include FvSimpleFileSystemDxe too in the
 build. (Or explain why I'm wrong :))


I think you're right. I fixed the ARM BDS menu, but booting an image
using the LinuxLoader does not actually work after applying the patch.
(Should have tested this more thoroughly, obviously). I will respin
and add the FvSimpleFileSystemDxe to the ARM+ARM_BDS build
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

2015-08-04 Thread Ard Biesheuvel
On 4 August 2015 at 10:07, Sharma Bhupesh bhupesh.sha...@freescale.com wrote:
 I have a related question. The EFI stub documentation (see [1]), seems to 
 suggest that
 we have the support to boot the kernel Image, DTB and Rootfs when supplied as
 separate images to the EFI stub.

 However, other Bootloaders like u-boot are supporting newer FIT image format 
 (see [2]), where
 these 3 images can be bundled into one and passed to the bootloader for 
 verification (both
 crc as well as cryptographic checks) and loading. This is supported on both 
 x86 and ARM platforms.

 At Freescale, we have a internal re-worked version of the ARM Bds Linux 
 Loader, where we can parse a FIT format
 Linux image and load Linux using the same on ARM64 platforms.


OK, first of all, I should point out that the ARM BDS does not adhere
to the UEFI spec regarding booting removable media. This means that,
as long as you use the ARM BDS, you will not be able to run OS
installers that have their GRUB or kernel image in
/EFI/BOOT/BOOTAA64.EFI, which is a default path defined by the spec.

 With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds 
 Linux Loader being deprecated,
 are there any plans to provide means to pass FIT format images via EFI_STUB 
 to the ARM64 Linux kernel?


No. FIT images are a U-Boot construct. The recommended way under UEFI
is to install the device tree as a FDT configuration table in the
firmware. Look at FdtPlatformDxe for more info. The initrd can be
loaded by the EFI stub, by passing the initrd= option.

The recommended way of doing authentication of bootable images is to
use UEFI Secure Boot. DTB authentication is implicit if it is part of
the UEFI image itself. How to do initrd authentication is undefined.

Regards,
Ard.

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
 Biesheuvel
 Sent: Tuesday, August 04, 2015 1:27 PM
 To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com
 Cc: ryan.har...@linaro.org; Ard Biesheuvel
 Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader
 changes

 LinuxLoader has been split off from the ARM BDS into a separate EFI
 application. Because we never included this application into the
 ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever
 since that change was merged.

 Let's fix the situation by:
 - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
   have UEFI stub support enabled by default, and the LinuxLoader code for
   booting arm64 Linux kernels is buggy. Note that this does not disable
   the ARM BDS text menu, it just removes the ability to boot bare Linux
   kernels.
 - Adding the LinuxLoader EFI application to the ARM builds.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---  ArmVirtPkg/ArmVirtQemu.dsc | 5
 +  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
  3 files changed, 14 insertions(+), 3 deletions(-)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index
 2e2708d1c281..735f9edc58d6 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]

 PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.in
 f

 MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAlloc
 ationLib.inf
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
 +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
 +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
 +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf

  [LibraryClasses.common.UEFI_DRIVER]

 ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLib
 Framework/DxeReportStatusCodeLib.inf
 @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]

gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE

 +[PcdsFeatureFlag.AARCH64]
 +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
 +
  [PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization
 Platform

 @@ -398,9 +404,6 @@ [Components.common]

 NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comman
 dsLib.inf

 NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comman
 dsLib.inf

 HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLi
 b.inf
 -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
 -
 FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
 -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf

 BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgComma
 ndLib.inf

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index
 a2a82a4dba8c..92d55c770f55 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b

[edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

2015-08-04 Thread Ard Biesheuvel
The ARM build still needs an intermediate loader to boot Linux,
since ARM/Linux has no builtin UEFI boot stub (yet).

So add the LinuxLoader UEFI application to the FV, and enable
the FvSimpleFileSystemDxe driver so that we can invoke the
Linux loader from the shell, e.g.,

  Shell linuxloader fs2:zImage -c console=ttyAMA0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
 ArmVirtPkg/ArmVirtQemu.dsc | 9 +
 ArmVirtPkg/ArmVirtQemu.fdf | 5 +
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 8c54242b597b..b1b0d049bc71 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -207,6 +207,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
@@ -399,9 +402,6 @@ [Components.common]
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 528d13e6aece..c020253587d0 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -367,3 +367,12 @@ [Components.common]
   MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
   MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+
+[Components.ARM]
+  #
+  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still need
+  # an intermediate OS loader. Add the LinuxLoader UEFI application so we can
+  # invoke it from the shell.
+  #
+  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index a9ad9ca6fe2d..6faf3bc12172 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -237,6 +237,11 @@ [FV.FvMain]
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
 
+!if $(ARCH) == ARM
+  INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+!endif
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
-- 
1.9.1

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


Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

2015-08-04 Thread Ard Biesheuvel
On 4 August 2015 at 16:50, Laszlo Ersek ler...@redhat.com wrote:
 On 08/04/15 16:34, Ard Biesheuvel wrote:
 On 4 August 2015 at 15:35, Laszlo Ersek ler...@redhat.com wrote:
[...]
 I propose the following:
 - The Xen hit should be removed as a separate patch, as it has never
   been useful. (The Xen build uses Intel BDS exclusively.)

 OK

 - The rest of the PCDs (in ArmVirtQemu.dsc and in ArmVirt.dsc.inc)
   should be removed as part of this patch. In practice, those are:
   - PcdFirmwareVendor (both files)
   - PcdDefaultConOutPaths (two instances)
   - PcdDefaultConInPaths (two instance)

 After you remove these, only
 gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType remains in this context,
 so please refresh both the leading comment, and the
 TTY_TERMINAL-dependent comments just below it. (They make references to
 ConOut/ConIn, and Intel BDS being optional.)


 I will remove the comment, since it suggests that ConIn/ConOut is
 unused under the Intel BDS, but that is clearly not the case.

 You refer to
 - gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths
 - gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths
 as being used by

   ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf

 That is correct. However, ArmVirtQemu.dsc does not resolve
 PlatformBdsLib to that instance; it uses

   ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf

 instead.

 Since your patch modifies ArmVirtQemu (where the ArmPlatformPkg library
 instance is unused), the PCDs should be removed.

 (The report files can be trusted about PCD usage.)

 The ArmPlatformPkg library instance is indeed used by ArmVirtXen, but
 the patch doesn't touch that file.


OK, good. I got confused by the fact that nothing under
ArmPlatformPkg/ actually uses this instance, but indeed, ArmVirtQemu
has its own.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 3/3] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

2015-08-04 Thread Ard Biesheuvel
The ARM build still needs an intermediate loader to boot Linux,
since ARM/Linux has no builtin UEFI boot stub (yet).

So add the LinuxLoader UEFI application to the FV, and enable
the FvSimpleFileSystemDxe driver so that we can invoke the
Linux loader from the shell, e.g.,

  Shell linuxloader fs2:zImage -c console=ttyAMA0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Laszlo Ersek ler...@redhat.com
---
 ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
 ArmVirtPkg/ArmVirtQemu.dsc | 9 +
 ArmVirtPkg/ArmVirtQemu.fdf | 5 +
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index ced45c8194bc..7bba6eba05a8 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
@@ -396,9 +399,6 @@ [Components.common]
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 5a644090be7c..61e95517259c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -354,3 +354,12 @@ [Components.common]
   MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
   MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+
+[Components.ARM]
+  #
+  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still need
+  # an intermediate OS loader. Add the LinuxLoader UEFI application so we can
+  # invoke it from the shell.
+  #
+  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index a9ad9ca6fe2d..6faf3bc12172 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -237,6 +237,11 @@ [FV.FvMain]
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
 
+!if $(ARCH) == ARM
+  INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+!endif
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
-- 
1.9.1

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


[edk2] [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

2015-08-04 Thread Ard Biesheuvel
This series is a followup to the patches
  'ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default'
and
  'ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build'
that I sent out earlier today. (The former was itself a replacement for
'ArmVirtPkg: align ARM BDS build with LinuxLoader changes', part of which
has been brought back in patch #3 of this series)

The ARM BDS currently depends on the LinuxLoader UEFI application to be
present in an FV, and it to be loadable and executable via the protocols
installed by FvSimpleFileSystemDxe. The current ArmVirtQemu builds lack
both the UEFI application and the filesystem driver, and so these builds
have been broken ever since the LinuxLoader was split off into a separate
application.

The LinuxLoader for AARCH64 is buggy and violates the arm64 boot protocol,
and the ARM BDS violates the UEFI spec. So instead of restoring the ARM BDS
to working order, we drop it completely from the ArmVirtQemu platform.
(patch #1)

In patch #2, we remove a copy-pasted ARM BDS related PCD definition from the
Xen build that has never been used, as the Xen build is Intel BDS only.

Patch #3 adds support for the Linux loader to the ARM build of ArmVirtQemu
when running the Intel BDS. The LinuxLoader for 32-bit ARM implements the
boot protocol correctly (although some patches are pending to improve it in
some areas), and is actually required to boot a Linux kernel at all since
the ARM/Linux kernel has no UEFI stub support (yet).

Ard Biesheuvel (3):
  ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default
  ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD
  ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

 ArmVirtPkg/ArmVirt.dsc.inc | 11 ++
 ArmVirtPkg/ArmVirtQemu.dsc | 41 ++--
 ArmVirtPkg/ArmVirtQemu.fdf |  9 ++---
 ArmVirtPkg/ArmVirtXen.dsc  |  1 -
 4 files changed, 19 insertions(+), 43 deletions(-)

-- 
1.9.1

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


[edk2] [PATCH 1/3] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

2015-08-04 Thread Ard Biesheuvel
ARM BDS support in ArmVirtQemu has been broken since SVN r17969
(ArmPkg/BdsLib: Remove Linux loader from BdsLib) dated July 14th.

Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
altogether: they violate both the UEFI spec and the arm64 Linux boot
protocol, and lack the level of integration with the QEMU command
line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 ArmVirtPkg/ArmVirt.dsc.inc |  5 +--
 ArmVirtPkg/ArmVirtQemu.dsc | 32 ++--
 ArmVirtPkg/ArmVirtQemu.fdf |  6 
 3 files changed, 3 insertions(+), 40 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 8c54242b597b..ced45c8194bc 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -106,8 +106,7 @@ [LibraryClasses.common]
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
 
-  # BDS Libraries
-  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
+  # Flattened Device Tree (FDT) access library
   FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
 
   # PCI Libraries
@@ -279,8 +278,6 @@ [PcdsFeatureFlag.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
 
 [PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Virtualization Platform
-
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index c199cac72cfd..5a644090be7c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,13 +57,11 @@ [LibraryClasses.common]
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 
-!if $(INTEL_BDS) == TRUE
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
   PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
-!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
@@ -99,8 +97,6 @@ [PcdsFeatureFlag.common]
   gArmVirtTokenSpaceGuid.PcdKludgeMapPciMmioAsCached|TRUE
 
 [PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|QEMU
-
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
 !if $(ARCH) == AARCH64
   gArmTokenSpaceGuid.PcdVFPEnabled|1
@@ -127,29 +123,11 @@ [PcdsFixedAtBuild.common]
   ## PL011 - Serial Terminal
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
 
-  #
-  # ARM OS Loader
-  #
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on 
virtio31:hd0:part0
-  
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 
console=ttyAMA0 earlycon uefi_debug
-
-  #
-  # Settings for ARM BDS -- use the serial console (ConIn  ConOut).
-  #
-!if $(TTY_TERMINAL) == TRUE
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
-  ## Terminal Type - TTYTERM, consistent with ConOut/ConIn Device Path.
+  ## Default Terminal Type
   ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
+!if $(TTY_TERMINAL) == TRUE
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
 !else
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
-  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
-  ## When Intel BDS is enabled, the above ConOut/ConIn device path is useless,
-  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
-  ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
 !endif
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
@@ -175,10 +153,8 @@ [PcdsFixedAtBuild.common]
   # initial location of the device tree blob passed by QEMU -- base of DRAM
   gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
 
-!if $(INTEL_BDS) == TRUE

[edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD

2015-08-04 Thread Ard Biesheuvel
The PcdFirmwareVendor PCD was never used on this platform, since
it has never supported the ARM BDS. So remove it.

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

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index b4007ff3c6a4..06c0003ae893 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -79,7 +79,6 @@ [BuildOptions]
 

 
 [PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|XEN-UEFI
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L$(FIRMWARE_VER)
 
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
-- 
1.9.1

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