Re: [edk2] [Patch v2 4/4] Vlv2TbltDevicePkg/PlatformInitPei: Explicit call to dump MTRR Setting

[Wei, David]

Reviewed-by: David Wei  



Thanks,
David  Wei 

 Intel SSG BIOS Team


-Original Message-
From: Fan, Jeff 
Sent: Tuesday, July 19, 2016 1:59 PM
To: edk2-devel@lists.01.org
Cc: Wei, David ; Tian, Feng ; Kinney, 
Michael D ; Laszlo Ersek 
Subject: [Patch v2 4/4] Vlv2TbltDevicePkg/PlatformInitPei: Explicit call to 
dump MTRR Setting

Mtrr library instance removed MtrrDebugPrintAllMtrrs() from MtrrSetAllMtrrs() to
make MP safe. We need to explicitly call MtrrDebugPrintAllMtrrs() to dump MTRR
setting.

v2->v1:
  Remove DEBUG_CODE() due to the implementation of MtrrDebugPrintAllMtrrs()
  already added DEBUG_CODE() for all executable code.

CC: David Wei 
Cc: Feng Tian 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c 
b/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
index 9592b07..99bdeb1 100644
--- a/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
+++ b/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.



   This program and the accompanying materials are licensed and made available 
under

   the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -222,8 +222,10 @@ SetPeiCacheMode (
   MtrrSetting.MtrrDefType |=  3 <<10;
 
   MtrrSetAllMtrrs(&MtrrSetting);
-
-
+  //
+  // Dump MTRR Setting
+  //
+  MtrrDebugPrintAllMtrrs ();
 
   return EFI_SUCCESS;
 }
-- 
2.7.4.windows.1

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

Re: [edk2] Generated *.FV is bigger than it's contents

[Michael Zimmermann]

ok this is what's happening (in comparison to keeping FVMAIN_COMPACT in the
FD):
- the generated FVMAIN_COMPACT doesn't have the options EFI_BASE_ADDRESS
and EFI_NUM_BLOCKS, EFI_BLOCK_SIZE is 0x1
- this missing base causes FfsRebase to just return(I can actually see that
in the binary, because there are WAY more differences than just the reset
vector)
- since FfsRebase returned without doing anything, mArm is still false.
This line didn't get executed:
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3380
- since mArm is false, UpdateArmResetVectorIfNeeded is not getting called

as you can see there are two problems:
- no rebase
- caused by that, all the ARM specific handling like the reset vector
doesn't happen

Now, FV's support the 'FvBaseAddress' flag, after setting that I indeed get
a relocated binary, with a correct reset vector.

so, what I did, apart from setting the base address in the Fv section is
removing this line to not include the Fv in the FD:
'FV = FVMAIN_COMPACT'
Is this the correct way or is there more to it? I guess I have to keep all
the surrounding lines for generating the FD because it produces Pcd's
like PcdFdBaseAddress which are needed right?

Thanks for your help,
Michael

On Mon, Jul 18, 2016 at 11:54 PM, Andrew Fish  wrote:

>
> On Jul 18, 2016, at 2:25 PM, Michael Zimmermann 
> wrote:
>
> If I do that the file is as small as possible(yay), but not bootable
> anymore, i.e. the first 4 bytes are 0 instead of the instruction which
> jumps past the DOS header.
>
>
> The 1st 16-bytes of the FV header are defined to be a zero vector. This
> allows space for code that resets low, and is patched by the build tools.
>
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L2050
>
> It looks like GenFv will patch the start of the FV with a jmp to the
> _ModuleEntryPoint (The entry point in the PE/COFF header) of the SEC or
> PeiCore if they exist in the FV?
>
> You can poke around in that area to figure out why the patch did not
> happen.
>
> Thanks,
>
> Andrew Fish
>
> Thanks
> Michael
>
> On Mon, Jul 18, 2016 at 11:00 PM, Andrew Fish  wrote:
>
>>
>> > On Jul 18, 2016, at 1:42 PM, Michael Zimmermann <
>> sigmaepsilo...@gmail.com> wrote:
>> >
>> > > For example This statement in the [FD.MEMFD] section will cause this
>> region of the FLASH to get padded out if the FV is smaller than 0xA0
>> >
>> > that seems to be the problem because the Size in the FV header is set
>> to that value and the file FVMAIN_COMPACT.Fv always has that size.
>> >
>> > of course I could just make it smaller, but in this case I'd have to
>> adjust it to the current size and increase it every time I need more space
>> to fix the build error.
>> > It would be easier to just be able to remove the 0xFF padding for the
>> FV, or at least have a clean way to remove it afterwards by external tools.
>> >
>> > to make things easier I'll link my source here:
>> >
>> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
>> <
>> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
>> >
>> >
>>
>> What is the size of the FVMAIN_COMPACT if you don't place it in the FD?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> > Thanks
>> > Michael
>> >
>> >
>> > On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish > af...@apple.com>> wrote:
>> >
>> > > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann <
>> sigmaepsilo...@gmail.com > wrote:
>> > >
>> > >
>> > > I don't need/use XIP or relocation(would the latter make a difference
>> > > anyway?).
>> > >
>> > > Also the difference between FD and FV seems to be terminology only,
>> because
>> > > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
>> > >
>> > > What I successfully tested as a workaround is reading
>> > > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to
>> that
>> > > size.
>> > > That seems to work, but I'm not sure if it's exact, because there are
>> still
>> > > a few 0xff bytes left and I'm not sure if these really are for
>> aligning the
>> > > size only.
>> > >
>> >
>> > Michael,
>> >
>> > The FD is a collection of FVs and Data regions output by the build
>> system. If all you have is an FV you should just use that. You can reduce
>> the padding by setting the BlockSize smaller. The FvAlignment value
>> (commonly 16) would be a good value to try. Any padding after that is
>> coming from the FD creation:
>> >
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91
>> > >
>> >
>> > 0x10|0xA0
>> >
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>> > FV = DXEFV
>> >
>> > For example This statement in the [FD.MEMFD] section will cause this
>> region of the FLASH to get padded out if the FV is smaller than 0xA0
>> >
>

[edk2] [Patch v2 4/4] Vlv2TbltDevicePkg/PlatformInitPei: Explicit call to dump MTRR Setting

[Jeff Fan]

Mtrr library instance removed MtrrDebugPrintAllMtrrs() from MtrrSetAllMtrrs() to
make MP safe. We need to explicitly call MtrrDebugPrintAllMtrrs() to dump MTRR
setting.

v2->v1:
  Remove DEBUG_CODE() due to the implementation of MtrrDebugPrintAllMtrrs()
  already added DEBUG_CODE() for all executable code.

CC: David Wei 
Cc: Feng Tian 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c 
b/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
index 9592b07..99bdeb1 100644
--- a/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
+++ b/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.



   This program and the accompanying materials are licensed and made available 
under

   the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -222,8 +222,10 @@ SetPeiCacheMode (
   MtrrSetting.MtrrDefType |=  3 <<10;
 
   MtrrSetAllMtrrs(&MtrrSetting);
-
-
+  //
+  // Dump MTRR Setting
+  //
+  MtrrDebugPrintAllMtrrs ();
 
   return EFI_SUCCESS;
 }
-- 
2.7.4.windows.1

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

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: SMM_CPU_DATA_BLOCK is not cleared

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, July 19, 2016 10:58 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff ; Tian, Feng 
Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: SMM_CPU_DATA_BLOCK is not cleared

From: Jeff Fan 

The commit 8b9311 changed the zeroing of mSmmMpSyncData of type 
SMM_DISPATCHER_MP_SYNC_DATA by the following patch.
 -ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
 +mSmmMpSyncData->SwitchBsp = FALSE;

mSmmMpSyncDataSize not only includes SMM_DISPATCHER_MP_SYNC_DATA, but also 
includes the SMM_CPU_DATA_BLOCK array and one BOOLEAN variable array as shown 
here:

  mSmmMpSyncDataSize = sizeof (SMM_DISPATCHER_MP_SYNC_DATA) +
   (sizeof (SMM_CPU_DATA_BLOCK) + sizeof (BOOLEAN)) *
   gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus;

This patch restores the original ZeroMem() to clear all CPU Sync data. The 
commit 8b9311 may cause unexpected behavior.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 5ba0514..fe9076b 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1276,7 +1276,10 @@ InitializeMpSyncData (
   UINTN  CpuIndex;
 
   if (mSmmMpSyncData != NULL) {
-mSmmMpSyncData->SwitchBsp = FALSE;
+//
+// mSmmMpSyncDataSize includes SMM_DISPATCHER_MP_SYNC_DATA and 
SMM_CPU_DATA_BLOCK range
+//
+ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
 mSmmMpSyncData->CpuData = (SMM_CPU_DATA_BLOCK *)((UINT8 *)mSmmMpSyncData + 
sizeof (SMM_DISPATCHER_MP_SYNC_DATA));
 mSmmMpSyncData->CandidateBsp = (BOOLEAN *)(mSmmMpSyncData->CpuData + 
gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus);
 if (FeaturePcdGet (PcdCpuSmmEnableBspElection)) {
--
2.6.3.windows.1

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

Re: [edk2] [PATCH] ShellPkg: Fix VS2010/2012 build failure

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Tuesday, July 19, 2016 10:27 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: [PATCH] ShellPkg: Fix VS2010/2012 build failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Dandan Bi 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
index 90eafe5..28c37ee 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
@@ -52,6 +52,7 @@ ShellCommandRunEfiDecompress (
   InFileName  = NULL;
   OutFileName = NULL;
   OutSize = 0;
+  ScratchSize = 0;
   ShellStatus = SHELL_SUCCESS;
   Status  = EFI_SUCCESS;
   OutBuffer   = NULL;
@@ -59,6 +60,7 @@ ShellCommandRunEfiDecompress (
   ScratchBuffer   = NULL;
   InFileHandle= NULL;
   OutFileHandle   = NULL;
+  Decompress  = NULL;
 
   //
   // initialize the shell lib (we must be in non-auto-init...)
-- 
2.9.0.windows.1

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

[edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: SMM_CPU_DATA_BLOCK is not cleared

[Michael Kinney]

From: Jeff Fan 

The commit 8b9311 changed the zeroing of mSmmMpSyncData of type
SMM_DISPATCHER_MP_SYNC_DATA by the following patch.
 -ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
 +mSmmMpSyncData->SwitchBsp = FALSE;

mSmmMpSyncDataSize not only includes SMM_DISPATCHER_MP_SYNC_DATA,
but also includes the SMM_CPU_DATA_BLOCK array and one BOOLEAN
variable array as shown here:

  mSmmMpSyncDataSize = sizeof (SMM_DISPATCHER_MP_SYNC_DATA) +
   (sizeof (SMM_CPU_DATA_BLOCK) + sizeof (BOOLEAN)) *
   gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus;

This patch restores the original ZeroMem() to clear all CPU
Sync data. The commit 8b9311 may cause unexpected behavior.

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index 5ba0514..fe9076b 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1276,7 +1276,10 @@ InitializeMpSyncData (
   UINTN  CpuIndex;
 
   if (mSmmMpSyncData != NULL) {
-mSmmMpSyncData->SwitchBsp = FALSE;
+//
+// mSmmMpSyncDataSize includes SMM_DISPATCHER_MP_SYNC_DATA and 
SMM_CPU_DATA_BLOCK range
+//
+ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
 mSmmMpSyncData->CpuData = (SMM_CPU_DATA_BLOCK *)((UINT8 *)mSmmMpSyncData + 
sizeof (SMM_DISPATCHER_MP_SYNC_DATA));
 mSmmMpSyncData->CandidateBsp = (BOOLEAN *)(mSmmMpSyncData->CpuData + 
gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus);
 if (FeaturePcdGet (PcdCpuSmmEnableBspElection)) {
-- 
2.6.3.windows.1

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

[edk2] [PATCH] ShellPkg: Fix VS2010/2012 build failure

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Dandan Bi 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
index 90eafe5..28c37ee 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
@@ -52,6 +52,7 @@ ShellCommandRunEfiDecompress (
   InFileName  = NULL;
   OutFileName = NULL;
   OutSize = 0;
+  ScratchSize = 0;
   ShellStatus = SHELL_SUCCESS;
   Status  = EFI_SUCCESS;
   OutBuffer   = NULL;
@@ -59,6 +60,7 @@ ShellCommandRunEfiDecompress (
   ScratchBuffer   = NULL;
   InFileHandle= NULL;
   OutFileHandle   = NULL;
+  Decompress  = NULL;
 
   //
   // initialize the shell lib (we must be in non-auto-init...)
-- 
2.9.0.windows.1

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

Re: [edk2] [PATCH v3 6/9] MdePkg: disallow open coded varargs implementation on optimizing GCC

[Gao, Liming]

Ard:
  This logic can't be met. I suggest to remove it and add comments to say this 
condition is invalid.

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Monday, July 18, 2016 2:01 PM
To: Gao, Liming 
Cc: br...@cran.org.uk; Ye, Ting ; Justen, Jordan L 
; edk2-devel@lists.01.org; af...@apple.com; Long, 
Qin ; Kinney, Michael D ; 
pbonz...@redhat.com; ler...@redhat.com
Subject: Re: [edk2] [PATCH v3 6/9] MdePkg: disallow open coded varargs 
implementation on optimizing GCC

On 18 July 2016 at 07:56, Gao, Liming wrote:
> Ard:
>
> The below condition can't be trigged. It is in the else path of #elif 
> defined(__GNUC__). So, #if defined(__GNUC__) is always FALSE in below case. 
> Are they added for comment only?
>

This is only the case after the next patch removes the '&&
!defined(NO_BUILTIN_VA_FUNCS)' from the __GNUC__ test. But you are
right that at that point, the condition can no longer be met.

I think it does make sense to keep it, since the combination is known
to generate broken binaries, but I am happy to drop the patch if other
people feel this is not necessary.

--
Ard.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Sunday, July 17, 2016 6:35 PM
>> To: edk2-devel@lists.01.org; 
>> ler...@redhat.com; 
>> af...@apple.com; Gao,
>> Liming ; Shi, Steven ; Zhu,
>> Yonghong ; Kinney, Michael D
>> ; Justen, Jordan L
>> Cc: br...@cran.org.uk; 
>> pbonz...@redhat.com; Ard Biesheuvel
>> ; Ye, Ting ; Long, Qin
>>
>> Subject: [edk2] [PATCH v3 6/9] MdePkg: disallow open coded varargs
>> implementation on optimizing GCC
>>
>> The open coded varargs implementation that performs pointer arithmetic on
>> the last named parameter of a function to calculate the addresses of
>> variadic parameters and subsequently derefences them is fragile, and break
>> spectacularly when used under GCC with optimization enabled. So explicitly
>> disallow this combination.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel
>> ---
>> MdePkg/Include/Base.h | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
>> index e03fa8239284..95400f993e6b 100644
>> --- a/MdePkg/Include/Base.h
>> +++ b/MdePkg/Include/Base.h
>> @@ -635,6 +635,11 @@ typedef __builtin_va_list VA_LIST;
>> #endif
>>
>> #else
>> +
>> +#if defined(__GNUC__) && defined(__OPTIMIZE__)
>> +#error This VA_LIST implementation is incompatible with GCC optimization
>> +#endif
>> +
>> ///
>> /// Variable used to traverse the list of arguments. This type can vary by
>> /// implementation and could be an array or structure.
>> --
>> 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 4/4] Vlv2TbltDevicePkg/PlatformInitPei: Explicit call to dump MTRR Setting

[Jeff Fan]

Mtrr library instance removed MtrrDebugPrintAllMtrrs() from MtrrSetAllMtrrs() to
make MP safe. We need to explicitly call MtrrDebugPrintAllMtrrs() to dump MTRR
setting.

CC: David Wei 
Cc: Feng Tian 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c 
b/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
index 9592b07..f592519 100644
--- a/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
+++ b/Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.



   This program and the accompanying materials are licensed and made available 
under

   the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -222,8 +222,10 @@ SetPeiCacheMode (
   MtrrSetting.MtrrDefType |=  3 <<10;
 
   MtrrSetAllMtrrs(&MtrrSetting);
-
-
+  //
+  // Dump MTRR Setting
+  //
+  DEBUG_CODE (MtrrDebugPrintAllMtrrs ());
 
   return EFI_SUCCESS;
 }
-- 
2.7.4.windows.1

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

[edk2] [Patch 3/4] UefiCpuPkg/MtrrLib: Add notes for usage by BSP/APs

[Jeff Fan]

Except for MtrrSetAllMtrrs(), others services are not suggested to be invoked by
APs because they are not necessary and may invoke DEBUG() to dump MTRR setting.

Cc: Feng Tian 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index f667a8f..5aef772 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -1,6 +1,10 @@
 /** @file
   MTRR setting library
 
+  @par Note: 
+Most of services in this library instance are suggested to be invoked by 
BSP only,
+except for MtrrSetAllMtrrs() which is used to sync BSP's MTRR setting to 
APs.
+
   Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
-- 
2.7.4.windows.1

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

[edk2] [Patch 2/4] UefiCpuPkg/MtrrLib: Remove MTRRs display from MtrrSetAllMtrrs()

[Jeff Fan]

MtrrSetAllMtrrs() maybe used by APs to sync BSP's MTRR settings. BSP's MTRR
setting should be displayed if EFI_D_CACHE flag is set when MTRR updated. In
MtrrSetAllMtrrs(), it's not necessary to display MTRR setting again due to the
MTRR settings should be always same among BSP/APs. This updating could avoid
APs output MTRR setting at the same time and make display message corrupted.

Cc: Feng Tian 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Michael Kinney 
---
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c 
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 6a6bf76..f667a8f 100644
--- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
+++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
@@ -2103,8 +2103,6 @@ MtrrSetAllMtrrs (
 
   PostMtrrChangeEnableCache (&MtrrContext);
 
-  MtrrDebugPrintAllMtrrs ();
-
   return MtrrSetting;
 }
 
-- 
2.7.4.windows.1

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

[edk2] [Patch 1/4] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode

[Jeff Fan]

SetMemoryAttributes() will sync BSP's MTRRs settings to all APs by StartupAllAPs
service in serial mode. It may caused much performance impact if there are too
much processors in system. This update is to invoke StartupAllAps in parallel
mode. IA32 SDM does suggest to program MTRRs in parallel mode.

Cc: Michael Kinney 
Cc: Feng Tian 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Feng Tian 
---
 UefiCpuPkg/CpuDxe/CpuDxe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index daf97bd..78b2c88 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -1,7 +1,7 @@
 /** @file
   CPU DXE Module.
 
-  Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -422,7 +422,7 @@ CpuSetMemoryAttributes (
   MpStatus = MpService->StartupAllAPs (
   MpService,  // This
   SetMtrrsFromBuffer, // Procedure
-  TRUE,   // SingleThread
+  FALSE,  // SingleThread
   NULL,   // WaitEvent
   0,  // TimeoutInMicrosecsond
   &MtrrSettings,  // ProcedureArgument
-- 
2.7.4.windows.1

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

[edk2] [Patch 0/4] UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode

[Jeff Fan]

This serial of patches are to sync APs' MTRR setting in parallel mode instead of
serialize mode and remove MTRRs setting display from MtrrSetAllMtrrs() to avoid
dump message corrupted by multiple processor executing.

Added the following r-b signatures on patch 2/4.
  Reviewed-by: Laszlo Ersek 
  Reviewed-by: Michael Kinney 

Jeff Fan (4):
  UefiCpuPkg/CpuDxe: StartupAllAPs in parallel mode
  UefiCpuPkg/MtrrLib: Remove MTRRs display from MtrrSetAllMtrrs()
  UefiCpuPkg/MtrrLib: Add notes for usage by BSP/APs
  Vlv2TbltDevicePkg/PlatformInitPei: Explicit call to dump MTRR Setting

 UefiCpuPkg/CpuDxe/CpuDxe.c | 4 ++--
 UefiCpuPkg/Library/MtrrLib/MtrrLib.c   | 6 --
 Vlv2TbltDevicePkg/PlatformInitPei/MemoryPeim.c | 8 +---
 3 files changed, 11 insertions(+), 7 deletions(-)

-- 
2.7.4.windows.1

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

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

[Laszlo Ersek]

On 07/17/16 12:34, Ard Biesheuvel wrote:
> This is v3 of the series to enable compiler optimization under GCC for builds
> targetting X64. It includes a patch from Steven Shi, taken from his series to
> introduce support for GCC 5.x and Clang 3.8/X64 to EDK2.
> 
> The first patch fixes the issue that __builtin_unreachable() is not
> implemented by GCC 4.4 or earlier.
> 
> Patch #2 sets a new define for OpensslLib that we will test in patches #3
> and #4 to inhibit the use of the MS varargs ABI when building OpenSSL, which
> lacks the ms_abi attributes on its variadic functions.
> 
> Patch #3 is Steven's patch to switch to the flavor of VA_LIST that is
> explicitly modeled after the MS implementation. This by itself is an
> improvement, since the open coded implementation that performs arithmetic
> on the address of explicit arguments to obtain the variadic arguments is
> fragile and difficult to maintain, and should be best avoided.
> 
> Patch #4 ports patch #3 to EdkCompatibilityPkg
> 
> Patch #5 enables -Os optimization for X64/RELEASE and X86/DEBUG all the way
> back to GCC44. This aligns X64 with IA32, which is already built using -Os
> for both DEBUG and RELEASE.
> 
> Note that the reported breakage regarding the use of -Os [0] is likely caused
> by the poor man's __builtin_ms_va_list (NO_BUILTIN_VA_FUNCS) that we used for
> GCC/X64 before Steven's patch above switches us to a properly defined builtin
> type. (The poor man's implementation uses pointer arithmetic involving the
> address of the last named argument to calculate pointers to the variadic
> arguments and dereferences them to obtain the argument values. I'm quite
> surprised it works as well as it does at -O0, to be honest)
> 
> I tested this change with both Ovmf and EmulatorPkg built in various ways
> and with various versions, with the caveat that I did not always use a 
> matching
> binutils (i.e., of the same era). Since the issues this series deal with are
> all code generation issues, I think this is reasonable, but more testing would
> be appreciated. (v2: this still applies, I have tested DEBUG and RELEASE 
> builds
> using GCC44, GCC46, GCC47 and GCC48, but all on the same Ubuntu 14.04 system,
> which means they all use the same ld version 2.24.90)
> 
> [0] http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963
> 
> Patch #6 explicitly forbids the poor man's MS ABI varargs implementation when
> using GCC with optimization enabled.
> 
> Patch #7 drops checks for the NO_BUILTIN_VA_FUNCS macro, which is never 
> defined
> anymore.
> 
> Patch #8 applies the visibility 'protected' GCC pragma globally. Please refer 
> to
> the commit log for the motivation.
> 
> Patch #9 switches GCC/X64 to the PIE small code model, which results in 
> smaller
> code.
> 
> Changes in v3:
> - Ensure OpensslLib does not switch to the MS varargs ABI inadvertently
> - Switch to -fpie code generation rather than -fpic, which is more suitable 
> for
>   executables. Note that this is *not* the -pie linker switch which generates
>   a RELA section and a _DYNAMIC entrypoint.
> - Use 'protected' rather than 'hidden' visibility, which is equally suitable 
> for
>   our purposes (inhibiting generation of GOT entries) but interoperates better
>   with LTO, which we intend to enable for GCC 5 and up
> - dropped Laszlo's 'tested-by' from all patches, which was given based on v1

Tested-by: Laszlo Ersek 

I built those 42 configs again. They all succeeded. I'll send you the
logs off-list so you can check the gcc command lines etc.

I also did some light SB checking, key enrollment, binary rejection and
acceptance.

Thanks
Laszlo

> Branch can be found here
> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/gcc-x64-opt-v3
> 
> Changes in v2:
> - Switch to -Os optimization, both for DEBUG and RELEASE builds. This turns 
> out
> to work fine (as far as I could establish) and gives the best results in terms
> of code size.
> 
> Ard Biesheuvel (8):
>   MdePkg: avoid __builtin_unreachable() on GCC v4.4
>   CryptoPkg: set new define to avoid MS ABI VA_LIST on GCC/X64
>   EdkCompatibilityPkg: Enable new MS VA intrinsics for GNUC x86 64bits
> build
>   BaseTools/tools_def: enable Os optimization for GCC X64 builds
>   MdePkg: disallow open coded varargs implementation on optimizing GCC
>   MdePkg CryptoPkg EdkCompatibilityPkg: retire NO_BUILTIN_VA_FUNCS
> define
>   MdePkg X64: force 'protected' visibility when building with -fpic
>   BaseTools/tools_def: switch GCC/X64 to the PIE small model
> 
> Shi, Steven (1):
>   MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build
> 
>  BaseTools/Conf/tools_def.template  |  2 +-
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  2 +-
>  EdkCompatibilityPkg/Foundation/Include/EfiStdArg.h | 28 ++-
>  MdePkg/Include/Base.h  | 36 ++--
>  MdePkg/Include/X64/ProcessorBind.h |  9 +
>  5 files ch

Re: [edk2] Generated *.FV is bigger than it's contents

[Andrew Fish]

> On Jul 18, 2016, at 2:25 PM, Michael Zimmermann  
> wrote:
> 
> If I do that the file is as small as possible(yay), but not bootable anymore, 
> i.e. the first 4 bytes are 0 instead of the instruction which jumps past the 
> DOS header.
> 

The 1st 16-bytes of the FV header are defined to be a zero vector. This allows 
space for code that resets low, and is patched by the build tools. 

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L2050

It looks like GenFv will patch the start of the FV with a jmp to the 
_ModuleEntryPoint (The entry point in the PE/COFF header) of the SEC or PeiCore 
if they exist in the FV? 

You can poke around in that area to figure out why the patch did not happen. 

Thanks,

Andrew Fish

> Thanks
> Michael
> 
> On Mon, Jul 18, 2016 at 11:00 PM, Andrew Fish  > wrote:
> 
> > On Jul 18, 2016, at 1:42 PM, Michael Zimmermann  > > wrote:
> >
> > > For example This statement in the [FD.MEMFD] section will cause this 
> > > region of the FLASH to get padded out if the FV is smaller than 0xA0
> >
> > that seems to be the problem because the Size in the FV header is set to 
> > that value and the file FVMAIN_COMPACT.Fv always has that size.
> >
> > of course I could just make it smaller, but in this case I'd have to adjust 
> > it to the current size and increase it every time I need more space to fix 
> > the build error.
> > It would be easier to just be able to remove the 0xFF padding for the FV, 
> > or at least have a clean way to remove it afterwards by external tools.
> >
> > to make things easier I'll link my source here:
> > https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
> >  
> > 
> >  
> >  >  
> > >
> >
> 
> What is the size of the FVMAIN_COMPACT if you don't place it in the FD?
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks
> > Michael
> >
> >
> > On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish  >  >> 
> > wrote:
> >
> > > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann  > >   > > >> wrote:
> > >
> > >
> > > I don't need/use XIP or relocation(would the latter make a difference
> > > anyway?).
> > >
> > > Also the difference between FD and FV seems to be terminology only, 
> > > because
> > > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
> > >
> > > What I successfully tested as a workaround is reading
> > > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to that
> > > size.
> > > That seems to work, but I'm not sure if it's exact, because there are 
> > > still
> > > a few 0xff bytes left and I'm not sure if these really are for aligning 
> > > the
> > > size only.
> > >
> >
> > Michael,
> >
> > The FD is a collection of FVs and Data regions output by the build system. 
> > If all you have is an FV you should just use that. You can reduce the 
> > padding by setting the BlockSize smaller. The FvAlignment value (commonly 
> > 16) would be a good value to try. Any padding after that is coming from the 
> > FD creation:
> > https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91 
> >  
> >  > >
> >
> > 0x10|0xA0
> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> > FV = DXEFV
> >
> > For example This statement in the [FD.MEMFD] section will cause this region 
> > of the FLASH to get padded out if the FV is smaller than 0xA0
> >
> > The FV will start with an EFI_FIRMWARE_VOLUME_HEADER, 
> > https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105
> >  
> > 
> >  
> >  >  
> > >
> >  , so you can programmatically figure out how big it is if you need to copy 
> > it.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > Thanks
> > > Michael
> > >
> > > On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish  > >   > > >> wrote:
> > >
> > >>
> > >>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann <
> > >> sigmaepsil

Re: [edk2] Generated *.FV is bigger than it's contents

[Michael Zimmermann]

If I do that the file is as small as possible(yay), but not bootable
anymore, i.e. the first 4 bytes are 0 instead of the instruction which
jumps past the DOS header.

Thanks
Michael

On Mon, Jul 18, 2016 at 11:00 PM, Andrew Fish  wrote:

>
> > On Jul 18, 2016, at 1:42 PM, Michael Zimmermann <
> sigmaepsilo...@gmail.com> wrote:
> >
> > > For example This statement in the [FD.MEMFD] section will cause this
> region of the FLASH to get padded out if the FV is smaller than 0xA0
> >
> > that seems to be the problem because the Size in the FV header is set to
> that value and the file FVMAIN_COMPACT.Fv always has that size.
> >
> > of course I could just make it smaller, but in this case I'd have to
> adjust it to the current size and increase it every time I need more space
> to fix the build error.
> > It would be easier to just be able to remove the 0xFF padding for the
> FV, or at least have a clean way to remove it afterwards by external tools.
> >
> > to make things easier I'll link my source here:
> >
> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
> <
> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
> >
> >
>
> What is the size of the FVMAIN_COMPACT if you don't place it in the FD?
>
> Thanks,
>
> Andrew Fish
>
> > Thanks
> > Michael
> >
> >
> > On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish  af...@apple.com>> wrote:
> >
> > > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann <
> sigmaepsilo...@gmail.com > wrote:
> > >
> > >
> > > I don't need/use XIP or relocation(would the latter make a difference
> > > anyway?).
> > >
> > > Also the difference between FD and FV seems to be terminology only,
> because
> > > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
> > >
> > > What I successfully tested as a workaround is reading
> > > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to that
> > > size.
> > > That seems to work, but I'm not sure if it's exact, because there are
> still
> > > a few 0xff bytes left and I'm not sure if these really are for
> aligning the
> > > size only.
> > >
> >
> > Michael,
> >
> > The FD is a collection of FVs and Data regions output by the build
> system. If all you have is an FV you should just use that. You can reduce
> the padding by setting the BlockSize smaller. The FvAlignment value
> (commonly 16) would be a good value to try. Any padding after that is
> coming from the FD creation:
> > https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91
> 
> >
> > 0x10|0xA0
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> > FV = DXEFV
> >
> > For example This statement in the [FD.MEMFD] section will cause this
> region of the FLASH to get padded out if the FV is smaller than 0xA0
> >
> > The FV will start with an EFI_FIRMWARE_VOLUME_HEADER,
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105
> <
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105>
> , so you can programmatically figure out how big it is if you need to copy
> it.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > Thanks
> > > Michael
> > >
> > > On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish  af...@apple.com>> wrote:
> > >
> > >>
> > >>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann <
> > >> sigmaepsilo...@gmail.com > wrote:
> > >>>
> > >>>
> > >>> Hi,
> > >>>
> > >>> I noticed that the size of YOURPLATFORM.fd always equals the size
> > >> specified
> > >>> in your fdf
> > >>> i.e. 4MB for 'Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize'.
> > >>>
> > >>> I don't know much about the case where this gets flashed to a nand
> and
> > >>> executed in place, but when using edk2 on a ARM PrePi device with
> edk2
> > >>> loaded into RAM, this looks like a huge waste of storage memory and
> > >> loading
> > >>> time to me.
> > >>>
> > >>> So, is it really important to have multiple MB(depending of you fv
> size
> > >>> ofc) of 0xff appended to the firmware or is there a fdf option or
> > >>> post-compilation tool to remove this?
> > >>>
> > >>
> > >> The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an
> > >> assumption it is a fixed size. If you want a flexible size you can
> use an
> > >> FV. Are you dependent on relocating the code so it can XIP? Is that
> what if
> > >> forcing the use of an FD?
> > >>
> > >> Just trying to figure out if what you are really asking for is the
> ability
> > >> to relocate an FV that is only as big as required? Maybe that is an
> FD,
> > >> maybe not?
> > >>
> > >> Short term if your FD is just a single FV you can use a PCD to know
> the
> > >> size and only copy that much data to the RAM. You would have to
> manually
> > >> pick an FD size that did not waist too much s

Re: [edk2] Generated *.FV is bigger than it's contents

[Andrew Fish]

> On Jul 18, 2016, at 1:42 PM, Michael Zimmermann  
> wrote:
> 
> > For example This statement in the [FD.MEMFD] section will cause this region 
> > of the FLASH to get padded out if the FV is smaller than 0xA0
> 
> that seems to be the problem because the Size in the FV header is set to that 
> value and the file FVMAIN_COMPACT.Fv always has that size.
> 
> of course I could just make it smaller, but in this case I'd have to adjust 
> it to the current size and increase it every time I need more space to fix 
> the build error.
> It would be easier to just be able to remove the 0xFF padding for the FV, or 
> at least have a clean way to remove it afterwards by external tools.
> 
> to make things easier I'll link my source here:
> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
>  
> 
> 

What is the size of the FVMAIN_COMPACT if you don't place it in the FD?

Thanks,

Andrew Fish

> Thanks
> Michael
> 
> 
> On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish  > wrote:
> 
> > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann  > > wrote:
> >
> >
> > I don't need/use XIP or relocation(would the latter make a difference
> > anyway?).
> >
> > Also the difference between FD and FV seems to be terminology only, because
> > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
> >
> > What I successfully tested as a workaround is reading
> > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to that
> > size.
> > That seems to work, but I'm not sure if it's exact, because there are still
> > a few 0xff bytes left and I'm not sure if these really are for aligning the
> > size only.
> >
> 
> Michael,
> 
> The FD is a collection of FVs and Data regions output by the build system. If 
> all you have is an FV you should just use that. You can reduce the padding by 
> setting the BlockSize smaller. The FvAlignment value (commonly 16) would be a 
> good value to try. Any padding after that is coming from the FD creation:
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91 
> 
> 
> 0x10|0xA0
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = DXEFV
> 
> For example This statement in the [FD.MEMFD] section will cause this region 
> of the FLASH to get padded out if the FV is smaller than 0xA0
> 
> The FV will start with an EFI_FIRMWARE_VOLUME_HEADER, 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105
>  
> 
>  , so you can programmatically figure out how big it is if you need to copy 
> it.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks
> > Michael
> >
> > On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish  > > wrote:
> >
> >>
> >>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann <
> >> sigmaepsilo...@gmail.com > wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I noticed that the size of YOURPLATFORM.fd always equals the size
> >> specified
> >>> in your fdf
> >>> i.e. 4MB for 'Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize'.
> >>>
> >>> I don't know much about the case where this gets flashed to a nand and
> >>> executed in place, but when using edk2 on a ARM PrePi device with edk2
> >>> loaded into RAM, this looks like a huge waste of storage memory and
> >> loading
> >>> time to me.
> >>>
> >>> So, is it really important to have multiple MB(depending of you fv size
> >>> ofc) of 0xff appended to the firmware or is there a fdf option or
> >>> post-compilation tool to remove this?
> >>>
> >>
> >> The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an
> >> assumption it is a fixed size. If you want a flexible size you can use an
> >> FV. Are you dependent on relocating the code so it can XIP? Is that what if
> >> forcing the use of an FD?
> >>
> >> Just trying to figure out if what you are really asking for is the ability
> >> to relocate an FV that is only as big as required? Maybe that is an FD,
> >> maybe not?
> >>
> >> Short term if your FD is just a single FV you can use a PCD to know the
> >> size and only copy that much data to the RAM. You would have to manually
> >> pick an FD size that did not waist too much storage.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Thanks
> >>> Michael
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org 
> >>>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7w

Re: [edk2] Generated *.FV is bigger than it's contents

[Michael Zimmermann]

> For example This statement in the [FD.MEMFD] section will cause this
region of the FLASH to get padded out if the FV is smaller than 0xA0

that seems to be the problem because the Size in the FV header is set to
that value and the file FVMAIN_COMPACT.Fv always has that size.

of course I could just make it smaller, but in this case I'd have to adjust
it to the current size and increase it every time I need more space to fix
the build error.
It would be easier to just be able to remove the 0xFF padding for the FV,
or at least have a clean way to remove it afterwards by external tools.

to make things easier I'll link my source here:
https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf

Thanks
Michael


On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish  wrote:

>
> > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann <
> sigmaepsilo...@gmail.com> wrote:
> >
> >
> > I don't need/use XIP or relocation(would the latter make a difference
> > anyway?).
> >
> > Also the difference between FD and FV seems to be terminology only,
> because
> > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
> >
> > What I successfully tested as a workaround is reading
> > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to that
> > size.
> > That seems to work, but I'm not sure if it's exact, because there are
> still
> > a few 0xff bytes left and I'm not sure if these really are for aligning
> the
> > size only.
> >
>
> Michael,
>
> The FD is a collection of FVs and Data regions output by the build system.
> If all you have is an FV you should just use that. You can reduce the
> padding by setting the BlockSize smaller. The FvAlignment value (commonly
> 16) would be a good value to try. Any padding after that is coming from the
> FD creation:
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91
>
> 0x10|0xA0
>
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = DXEFV
>
> For example This statement in the [FD.MEMFD] section will cause this
> region of the FLASH to get padded out if the FV is smaller than 0xA0
>
> The FV will start with an EFI_FIRMWARE_VOLUME_HEADER,
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105
> , so you can programmatically figure out how big it is if you need to copy
> it.
>
> Thanks,
>
> Andrew Fish
>
> > Thanks
> > Michael
> >
> > On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish  wrote:
> >
> >>
> >>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann <
> >> sigmaepsilo...@gmail.com> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I noticed that the size of YOURPLATFORM.fd always equals the size
> >> specified
> >>> in your fdf
> >>> i.e. 4MB for 'Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize'.
> >>>
> >>> I don't know much about the case where this gets flashed to a nand and
> >>> executed in place, but when using edk2 on a ARM PrePi device with edk2
> >>> loaded into RAM, this looks like a huge waste of storage memory and
> >> loading
> >>> time to me.
> >>>
> >>> So, is it really important to have multiple MB(depending of you fv size
> >>> ofc) of 0xff appended to the firmware or is there a fdf option or
> >>> post-compilation tool to remove this?
> >>>
> >>
> >> The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an
> >> assumption it is a fixed size. If you want a flexible size you can use
> an
> >> FV. Are you dependent on relocating the code so it can XIP? Is that
> what if
> >> forcing the use of an FD?
> >>
> >> Just trying to figure out if what you are really asking for is the
> ability
> >> to relocate an FV that is only as big as required? Maybe that is an FD,
> >> maybe not?
> >>
> >> Short term if your FD is just a single FV you can use a PCD to know the
> >> size and only copy that much data to the RAM. You would have to manually
> >> pick an FD size that did not waist too much storage.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Thanks
> >>> Michael
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7wYg-xu4aJ-6YGBqB4GTUNMVu1W9h8mqqf864YQ&e=
> >>
> >>
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=GBYUQYXoyDqknWeJcI64xlIkHnhnVmabgBV1ABmDeZs&s=QSUxiPKjBWf7bkI3IIL0E8JliL4vuwEWURFyB2oQQ0E&e=
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Generated *.FV is bigger than it's contents

[Andrew Fish]

> On Jul 18, 2016, at 9:07 AM, Michael Zimmermann  
> wrote:
> 
> 
> I don't need/use XIP or relocation(would the latter make a difference
> anyway?).
> 
> Also the difference between FD and FV seems to be terminology only, because
> YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
> 
> What I successfully tested as a workaround is reading
> EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to that
> size.
> That seems to work, but I'm not sure if it's exact, because there are still
> a few 0xff bytes left and I'm not sure if these really are for aligning the
> size only.
> 

Michael,

The FD is a collection of FVs and Data regions output by the build system. If 
all you have is an FV you should just use that. You can reduce the padding by 
setting the BlockSize smaller. The FvAlignment value (commonly 16) would be a 
good value to try. Any padding after that is coming from the FD creation:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91

0x10|0xA0
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
FV = DXEFV

For example This statement in the [FD.MEMFD] section will cause this region of 
the FLASH to get padded out if the FV is smaller than 0xA0

The FV will start with an EFI_FIRMWARE_VOLUME_HEADER, 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105
 , so you can programmatically figure out how big it is if you need to copy it. 

Thanks,

Andrew Fish

> Thanks
> Michael
> 
> On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish  wrote:
> 
>> 
>>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann <
>> sigmaepsilo...@gmail.com> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I noticed that the size of YOURPLATFORM.fd always equals the size
>> specified
>>> in your fdf
>>> i.e. 4MB for 'Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize'.
>>> 
>>> I don't know much about the case where this gets flashed to a nand and
>>> executed in place, but when using edk2 on a ARM PrePi device with edk2
>>> loaded into RAM, this looks like a huge waste of storage memory and
>> loading
>>> time to me.
>>> 
>>> So, is it really important to have multiple MB(depending of you fv size
>>> ofc) of 0xff appended to the firmware or is there a fdf option or
>>> post-compilation tool to remove this?
>>> 
>> 
>> The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an
>> assumption it is a fixed size. If you want a flexible size you can use an
>> FV. Are you dependent on relocating the code so it can XIP? Is that what if
>> forcing the use of an FD?
>> 
>> Just trying to figure out if what you are really asking for is the ability
>> to relocate an FV that is only as big as required? Maybe that is an FD,
>> maybe not?
>> 
>> Short term if your FD is just a single FV you can use a PCD to know the
>> size and only copy that much data to the RAM. You would have to manually
>> pick an FD size that did not waist too much storage.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Thanks
>>> Michael
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7wYg-xu4aJ-6YGBqB4GTUNMVu1W9h8mqqf864YQ&e=
>> 
>> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=GBYUQYXoyDqknWeJcI64xlIkHnhnVmabgBV1ABmDeZs&s=QSUxiPKjBWf7bkI3IIL0E8JliL4vuwEWURFyB2oQQ0E&e=

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

Re: [edk2] EFI PCI Root Bridge I/O and HII Image Decoder Protocol GUIDs

[Rothman, Michael A]

Let me preface my note with an "ugh!"

No, there has been no deprecation, this is an example of a bug that I'm 
extremely thankful was caught. 

For the record, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID in the spec is 
correct, and remains active and used.

There was a copy-paste bug in the EFI_HII_IMAGE_DECODER_PROTOCOL_GUID that 
despite the layers of checks and double-checks had somehow gotten past us all 
in the development of the spec.

Let's just say that the EFI_HII_IMAGE_DECODER_PROTOCOL_GUID will be fixed 
(changed) and the change reflected in a UEFI spec errata. I don't yet have a 
date for when that errata will come out, but I'll push for sooner vs later.

Thanks,
Mike Rothman 
(迈克 罗斯曼 / माइकल रोथ्मेन् / Михаил Ротман / משה רוטמן)
רועה עיקרי של חתולים


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
H?user
Sent: Monday, July 18, 2016 11:09 AM
To: edk2-devel@lists.01.org
Subject: [edk2] EFI PCI Root Bridge I/O and HII Image Decoder Protocol GUIDs

Dear community members,

I have just been searching MdePkg for a GUID unknown to me and - to my surprise 
- I found the same GUID twice in the code base: 
EFI_HII_IMAGE_DECODER_PROTOCOL_GUID and EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID. 
As former was added only recently, I went to check the UEFI 2.6 specification 
and discovered that even there the GUIDs match.

Now, please excuse my ignorance, but was the PCI Root Bridge I/O Protocol 
deprecated and the Image Decoder was assigned its GUID, or might this be a 
copy+paste error?
Also, in the specification, the Image Decore GUID has the second opening curly 
brace one byte too late, I suppose.

Regards,
Marvin.
___
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] EFI PCI Root Bridge I/O and HII Image Decoder Protocol GUIDs

[Marvin H?user]

Dear community members,

I have just been searching MdePkg for a GUID unknown to me and - to my surprise 
- I found the same GUID twice in the code base: 
EFI_HII_IMAGE_DECODER_PROTOCOL_GUID and EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID. 
As former was added only recently, I went to check the UEFI 2.6 specification 
and discovered that even there the GUIDs match.

Now, please excuse my ignorance, but was the PCI Root Bridge I/O Protocol 
deprecated and the Image Decoder was assigned its GUID, or might this be a 
copy+paste error?
Also, in the specification, the Image Decore GUID has the second opening curly 
brace one byte too late, I suppose.

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

Re: [edk2] [PATCH 0/5] build fixes

[Laszlo Ersek]

On 07/15/16 10:14, Laszlo Ersek wrote:
> So I've finally managed to set up VS2015x86 for test-building OVMF.
> Thanks Jordan and Liming for the instructions back in April (IIRC). The
> setup was a total pain, in no small part because there are three
> competing git implementations for Windows (cygwin, msys, and the
> standalone package from the git website (which is what I ultimately ran
> with)).
> 
> With these patches in place, I managed to build OVMF in my preferred
> configurations, for Ia32, Ia32X64, X64, each with GCC44 through GCC49,
> plus gcc-6.1 (using GCC49 settings), plus VS2015x86.
> 
> Cc: Andrew Fish 
> Cc: Jeff Fan 
> Cc: Jordan Justen 
> Cc: Liming Gao 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Cc: Yonghong Zhu 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   MdeModulePkg/PciHostBridgeDxe: fix Ia32 GCC44 build error
>   BaseTools/tools_def.template: bump minimum required NASM versions
>   UefiCpuPkg/PiSmmCpuDxeSmm: remove superfluous ENDs from NASM source
>   OvmfPkg/PciHostBridgeLib: silence IA32 VS2015x86 warnings
>   OvmfPkg/PlatformPei: silence X64 VS2015x86 warning
> 
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostResource.h | 2 +-
>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c   | 4 ++--
>  OvmfPkg/PlatformPei/MemDetect.c | 2 +-
>  BaseTools/Conf/tools_def.template   | 4 +++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.nasm| 2 --
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm | 1 -
>  6 files changed, 7 insertions(+), 8 deletions(-)
> 

I committed this (trivial) series with Liming's and Ray's reviews.
Commit range 35126af96ce8..fc3f005aee72. Thanks!

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

Re: [edk2] Generated *.FV is bigger than it's contents

[Michael Zimmermann]

I don't need/use XIP or relocation(would the latter make a difference
anyway?).

Also the difference between FD and FV seems to be terminology only, because
YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.

What I successfully tested as a workaround is reading
EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to that
size.
That seems to work, but I'm not sure if it's exact, because there are still
a few 0xff bytes left and I'm not sure if these really are for aligning the
size only.

Thanks
Michael

On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish  wrote:

>
> > On Jul 17, 2016, at 11:02 PM, Michael Zimmermann <
> sigmaepsilo...@gmail.com> wrote:
> >
> >
> > Hi,
> >
> > I noticed that the size of YOURPLATFORM.fd always equals the size
> specified
> > in your fdf
> > i.e. 4MB for 'Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize'.
> >
> > I don't know much about the case where this gets flashed to a nand and
> > executed in place, but when using edk2 on a ARM PrePi device with edk2
> > loaded into RAM, this looks like a huge waste of storage memory and
> loading
> > time to me.
> >
> > So, is it really important to have multiple MB(depending of you fv size
> > ofc) of 0xff appended to the firmware or is there a fdf option or
> > post-compilation tool to remove this?
> >
>
> The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an
> assumption it is a fixed size. If you want a flexible size you can use an
> FV. Are you dependent on relocating the code so it can XIP? Is that what if
> forcing the use of an FD?
>
> Just trying to figure out if what you are really asking for is the ability
> to relocate an FV that is only as big as required? Maybe that is an FD,
> maybe not?
>
> Short term if your FD is just a single FV you can use a PCD to know the
> size and only copy that much data to the RAM. You would have to manually
> pick an FD size that did not waist too much storage.
>
> Thanks,
>
> Andrew Fish
>
> > Thanks
> > Michael
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7wYg-xu4aJ-6YGBqB4GTUNMVu1W9h8mqqf864YQ&e=
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Generated *.FV is bigger than it's contents

[Andrew Fish]

> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann  
> wrote:
> 
> 
> Hi,
> 
> I noticed that the size of YOURPLATFORM.fd always equals the size specified
> in your fdf
> i.e. 4MB for 'Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize'.
> 
> I don't know much about the case where this gets flashed to a nand and
> executed in place, but when using edk2 on a ARM PrePi device with edk2
> loaded into RAM, this looks like a huge waste of storage memory and loading
> time to me.
> 
> So, is it really important to have multiple MB(depending of you fv size
> ofc) of 0xff appended to the firmware or is there a fdf option or
> post-compilation tool to remove this?
> 

The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an assumption it 
is a fixed size. If you want a flexible size you can use an FV. Are you 
dependent on relocating the code so it can XIP? Is that what if forcing the use 
of an FD? 

Just trying to figure out if what you are really asking for is the ability to 
relocate an FV that is only as big as required? Maybe that is an FD, maybe not?

Short term if your FD is just a single FV you can use a PCD to know the size 
and only copy that much data to the RAM. You would have to manually pick an FD 
size that did not waist too much storage. 

Thanks,

Andrew Fish

> Thanks
> Michael
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7wYg-xu4aJ-6YGBqB4GTUNMVu1W9h8mqqf864YQ&e=
>  

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

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

[Ard Biesheuvel]

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

Note that this requires the use of an wrapper script, since the GCC
toolchain family usually invokes the linker directly, whereas LTO
requires GCC to be invoked with the linker arguments decorated with
-Wl,xxx prefixes.

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Conf/tools_def.template   | 156 
 BaseTools/Scripts/lto-ld-wrapper.py |  39 +
 2 files changed, 195 insertions(+)

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

 #
 # Unix GCC And Intel Linux ACPI Compiler
@@ -5183,6 +5207,138 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
DEF(GCC49_AARCH64_DLINK_FLAGS)
 
 

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

[edk2] [PATCH v2 1/2] ArmPkg: add prebuilt glue binaries for GCC5 LTO support

[Ard Biesheuvel]

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

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

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/GccLto/liblto-aarch64.a | Bin 0 -> 1016 bytes
 ArmPkg/GccLto/liblto-aarch64.s |  15 ++
 ArmPkg/GccLto/liblto-arm.a | Bin 0 -> 2096 bytes
 ArmPkg/GccLto/liblto-arm.s |  49 
 4 files changed, 64 insertions(+)

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

literal 0
HcmV?d1

diff --git a/ArmPkg/GccLto/liblto-aarch64.s b/ArmPkg/GccLto/liblto-aarch64.s
new file mode 100644
index ..1215858edd43
--- /dev/null
+++ b/ArmPkg/GccLto/liblto-aarch64.s
@@ -0,0 +1,15 @@
+//
+// GCC in LTO mode interoperates poorly with non-standard libraries that
+// provide implementations of compiler intrinsics such as memcpy/memset
+// or the stack protector entry points.
+//
+// By referencing these functions from a non-LTO object that can be passed
+// to the linker via the -plugin-opt=-pass-through=-lxxx options, the
+// intrinsics are included in the link in a way that allows them to be
+// pruned again if no other references to them exist.
+//
+
+   .long   memcpy - .
+   .long   memset - .
+   .long   __stack_chk_fail - .
+   .long   __stack_chk_guard - .
diff --git a/ArmPkg/GccLto/liblto-arm.a b/ArmPkg/GccLto/liblto-arm.a
new file mode 100644
index 
..d811c09573a35ea87a8002ecf01be18e1c6e7fd3
GIT binary patch
literal 2096
zcmd6o%WKq76vn?XQ*C|Js#WW|YOD1@u(oJH7cHm=wjd(Xg%C3{sS}#eGD-SEunQLz
zT?o1mx)E36&V>ti;!4n^e}Mi6u3h<^n@J{fT}_x@dNmx{6!*W2si#P63O*VzW?IBihqh
z=)ig*pojKb#bw326`xc*toV}R>x!op&nRA0ysG%I;^&HAD}JZ=gW^w$zbO8u_=n=3
zihn6C7jA)^cemm`#e<4%#TOM%D88Zij$&7Fpm;^`6UFO_-zdgF4UQAVZgtkF)@Pj=
z*ALnp_Y=1vL)@s|sQDwQ6*Mh*7aYIlFNiybaLxo6PTG16rQHlllhBAv-k>#u2@Sol
zI=`G}CPrQiN;tRR(ak(*AdNItn6xb{AamTrttlr6972!~lYGJ?&mg`uh4`8leFjDu
zR1H=l|GXG+(@3h}e9gF`ML(|A$Jm)#Ny{9*kb6fYIz6K#U~GZXiE;<`AQQJZh#Ex*
zvPafpsg(EM+QeEU%F9+!7AJXjt<6BM=oX+)l${4fw*md4-N1n8cCac_8FW^32XIbw
zCm?m%V%-}PWwOhnEHdMwdw?sVdjY8%7AKh$-3Qzh-4EOrJpf1@u{il%(L=yJ(ZfJZ
z^axNF?FRzUqrklAF(4K_4lIdsu@6KCfmP8Hz#~x>xiwL4;;HB<;F;)Y;DzWJUhHT&
zjNJ+~ZlqeztcDlZv9}b%uDP)byAnmP`PA5M95?(*5_=I7{9EHzOij*-d{<&4d*_Y!hx!AINvPBvHw{hmarpIg2NWNZUrI#!p
wAAvlV^sI41<6<;hHcoUy=A?e-|05l;7C8giM-Tt9*KBPx@rv+1OG3`f-+dwCzyJUM

literal 0
HcmV?d1

diff --git a/ArmPkg/GccLto/liblto-arm.s b/ArmPkg/GccLto/liblto-arm.s
new file mode 100644
index ..48c682f92e08
--- /dev/null
+++ b/ArmPkg/GccLto/liblto-arm.s
@@ -0,0 +1,49 @@
+//
+// GCC in LTO mode interoperates poorly with non-standard libraries that
+// provide implementations of compiler intrinsics such as memcpy/memset
+// or the stack protector entry points.
+//
+// By referencing these functions from a non-LTO object that can be passed
+// to the linker via the -plugin-opt=-pass-through=-lxxx options, the
+// intrinsics are included in the link in a way that allows them to be
+// pruned again if no other references to them exist.
+//
+
+   .long   memcpy - .
+   .long   memset - .
+   .long   __stack_chk_fail - .
+   .long   __stack_chk_guard - .
+   .long __ashrdi3 - .
+   .long __ashldi3 - .
+   .long __aeabi_idiv - .
+   .long __aeabi_idivmod - .
+   .long __aeabi_uidiv - .
+   .long __aeabi_uidivmod - .
+   .long __divdi3 - .
+   .long __divsi3 - .
+   .long __lshrdi3 - .
+   .long __aeabi_memcpy - .
+   .long __aeabi_memset - .
+   .long memmove - .
+   .long __modsi3 - .
+   .long __moddi3 - .
+   .long __muldi3 - .
+   .long __aeabi_lmul - .
+   .long __ARM_ll_mullu - .
+   .long __udivsi3 - .
+   .long __umodsi3 - .
+   .long __udivdi3 - .
+

[edk2] [PATCH v3 5/5] ShellPkg: Fix echo to support displaying special characters

[Ruiyu Ni]

Run 'echo -t' without the patch will get the result:
  echo: Unknown flag - '-t'
  The expected result is to display '-t' literally.
  This patch adds special handle for 'echo'. 'echo' will not use the
  general parameter parsing library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Library/UefiShellLevel3CommandsLib/Echo.c | 141 +
 .../UefiShellLevel3CommandsLib.uni |   3 +-
 2 files changed, 63 insertions(+), 81 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Echo.c 
b/ShellPkg/Library/UefiShellLevel3CommandsLib/Echo.c
index a638de8..c98ee85 100644
--- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Echo.c
+++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Echo.c
@@ -2,7 +2,7 @@
   Main file for Echo shell level 3 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2012, Intel Corporation. All rights reserved. 
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved. 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -17,12 +17,6 @@
 
 #include 
 
-STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
-  {L"-on", TypeFlag},
-  {L"-off", TypeFlag},
-  {NULL, TypeMax}
-  };
-
 /**
   Function for 'echo' command.
 
@@ -36,86 +30,73 @@ ShellCommandRunEcho (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
-  EFI_STATUS  Status;
-  LIST_ENTRY  *Package;
-  SHELL_STATUSShellStatus;
-  UINTN   ParamCount;
-  CHAR16  *ProblemParam;
+  CHAR16  *RawCmdLine;
+  SHELL_STATUSStatus;
   UINTN   Size;
-  CHAR16  *PrintString;
-
-  Size= 0;
-  ProblemParam= NULL;
-  PrintString = NULL;
-  ShellStatus = SHELL_SUCCESS;
-
-  //
-  // initialize the shell lib (we must be in non-auto-init...)
-  //
-  Status = ShellInitialize();
-  ASSERT_EFI_ERROR(Status);
-
-  //
-  // parse the command line
-  //
-  Status = ShellCommandLineParseEx (ParamList, &Package, &ProblemParam, TRUE, 
TRUE);
-  if (EFI_ERROR(Status)) {
-if (Status == EFI_VOLUME_CORRUPTED && ProblemParam != NULL) {
-  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_PROBLEM), 
gShellLevel3HiiHandle, L"echo", ProblemParam);  
-  FreePool(ProblemParam);
-  ShellStatus = SHELL_INVALID_PARAMETER;
-} else {
-  ASSERT(FALSE);
-}
-  } else {
-//
-// check for "-?"
-//
-if (ShellCommandLineGetFlag(Package, L"-?")) {
-  ASSERT(FALSE);
+  CHAR16  *Walker;
+  CHAR16  *TempParameter;
+  BOOLEAN OnFlag;
+  BOOLEAN OffFlag;
+  UINTN   Count;
+
+  RawCmdLine = ShellGetRawCmdLine ();
+  if (RawCmdLine == NULL) {
+return SHELL_OUT_OF_RESOURCES;
+  }
+
+  OnFlag  = FALSE;
+  OffFlag = FALSE;
+
+  Size = StrSize (RawCmdLine);
+  TempParameter  = AllocateZeroPool(Size);
+  if (TempParameter == NULL) {
+Status = SHELL_OUT_OF_RESOURCES;
+goto Done;
+  }
+
+  for ( Count = 0
+  , Walker = RawCmdLine
+  ; Walker != NULL && *Walker != CHAR_NULL
+  ; Count++
+  ) {
+if (EFI_ERROR (ShellGetNextParameter (&Walker, TempParameter, Size, 
FALSE))) {
+  break;
 }
-if (ShellCommandLineGetFlag(Package, L"-on")) {
-  //
-  // Turn it on
-  //
-  ShellCommandSetEchoState(TRUE);
-} else if (ShellCommandLineGetFlag(Package, L"-off")) {
-  //
-  // turn it off
-  //
-  ShellCommandSetEchoState(FALSE);
-} else if (ShellCommandLineGetRawValue(Package, 1) == NULL) {
-  //
-  // output its current state
-  //
-  if (ShellCommandGetEchoState()) {
-ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_ECHO_ON), 
gShellLevel3HiiHandle);
-  } else {
-ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_ECHO_OFF), 
gShellLevel3HiiHandle);
+
+if (Count == 1) {
+  if (gUnicodeCollation->StriColl(gUnicodeCollation, TempParameter, 
L"-on") == 0 ) {
+OnFlag = TRUE;
   }
-} else {
-  //
-  // print the line
-  //
-  for ( ParamCount = 1
-  ; ShellCommandLineGetRawValue(Package, ParamCount) != NULL
-  ; ParamCount++
- ) {
-StrnCatGrow(&PrintString, &Size, ShellCommandLineGetRawValue(Package, 
ParamCount), 0);
-if (ShellCommandLineGetRawValue(Package, ParamCount+1) != NULL) {
-  StrnCatGrow(&PrintString, &Size, L" ", 0);
-} 
+  if (gUnicodeCollation->StriColl(gUnicodeCollation, TempParameter, 
L"-off") == 0 ) {
+OffFlag = TRUE;
   }
-  ShellPrintEx(-1, -1, L"%s\r\n", PrintString);
-  SHELL_FREE_NON_NULL(PrintString);
+}
+  }
+
+  if (OnFlag || OffFlag) {
+if (Count != 2) {
+  ShellPrintHiiEx(-1, -1, NULL, 

[edk2] [PATCH v3 2/5] ShellPkg/ShellCommandLib.h: Formalize EOL

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Include/Library/ShellCommandLib.h | 40 +++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/ShellPkg/Include/Library/ShellCommandLib.h 
b/ShellPkg/Include/Library/ShellCommandLib.h
index e3bb6e0..3ee8200 100644
--- a/ShellPkg/Include/Library/ShellCommandLib.h
+++ b/ShellPkg/Include/Library/ShellCommandLib.h
@@ -4,9 +4,9 @@
   This library is for use ONLY by shell commands linked into the shell 
application.
   This library will not funciton if it is used for UEFI Shell 2.0 Applications.
 
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
-  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
-  (C) Copyright 2013-2014 Hewlett-Packard Development Company, L.P.
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2013-2014 Hewlett-Packard Development Company, L.P.
   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
@@ -702,21 +702,21 @@ DumpHex (
   IN VOID *UserData
   );
 
-/**
-  Dump HEX data into buffer.
-   
-  @param[in] Buffer HEX data to be dumped in Buffer.
-  @param[in] Indent How many spaces to indent the output.
-  @param[in] Offset The offset of the printing.
-  @param[in] DataSize   The size in bytes of UserData.
-  @param[in] UserData   The data to print out.
-**/
-CHAR16*
-CatSDumpHex (
-  IN CHAR16  *Buffer,
-  IN UINTN   Indent,
-  IN UINTN   Offset,
-  IN UINTN   DataSize,
-  IN VOID*UserData
-  );
+/**
+  Dump HEX data into buffer.
+
+  @param[in] Buffer HEX data to be dumped in Buffer.
+  @param[in] Indent How many spaces to indent the output.
+  @param[in] Offset The offset of the printing.
+  @param[in] DataSize   The size in bytes of UserData.
+  @param[in] UserData   The data to print out.
+**/
+CHAR16*
+CatSDumpHex (
+  IN CHAR16  *Buffer,
+  IN UINTN   Indent,
+  IN UINTN   Offset,
+  IN UINTN   DataSize,
+  IN VOID*UserData
+  );
 #endif //_SHELL_COMMAND_LIB_
-- 
2.9.0.windows.1

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

[edk2] [PATCH v3 4/5] ShellPkg: Add Shell[Get|Set]RawCmdLine to ShellCommandLib

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Include/Library/ShellCommandLib.h | 23 +++
 .../UefiShellCommandLib/UefiShellCommandLib.c  | 45 ++
 2 files changed, 68 insertions(+)

diff --git a/ShellPkg/Include/Library/ShellCommandLib.h 
b/ShellPkg/Include/Library/ShellCommandLib.h
index 5c5e241..44eccc4 100644
--- a/ShellPkg/Include/Library/ShellCommandLib.h
+++ b/ShellPkg/Include/Library/ShellCommandLib.h
@@ -670,6 +670,29 @@ ShellFileHandleEof(
   IN SHELL_FILE_HANDLE Handle
   );
 
+/**
+  Function to get the original CmdLine string for current command.
+
+  @return A pointer to the buffer of the original command string.
+  It's the caller's responsibility to free the buffer.
+**/
+CHAR16*
+EFIAPI
+ShellGetRawCmdLine (
+  VOID
+  );
+
+/**
+  Function to store the orgignal command string into mOriginalCmdLine.
+
+  @param[in] CmdLine the command line string to store.
+**/
+VOID
+EFIAPI
+ShellSetRawCmdLine (
+  IN CONST CHAR16 *CmdLine
+  );
+
 typedef struct {
   LIST_ENTRYLink;
   void  *Buffer;
diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 6283f28..82f3bed 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -30,6 +30,7 @@ STATIC UINTN  mProfileListSize;
 STATIC UINTN  mFsMaxCount = 0;
 STATIC UINTN  mBlkMaxCount = 0;
 STATIC BUFFER_LISTmFileHandleList;
+STATIC CHAR16 *mRawCmdLine = NULL;
 
 STATIC CONST CHAR8 Hex[] = {
   '0',
@@ -1849,6 +1850,50 @@ ShellFileHandleEof(
 }
 
 /**
+  Function to get the original CmdLine string for current command.
+
+  @return A pointer to the buffer of the original command string.
+  It's the caller's responsibility to free the buffer.
+**/
+CHAR16*
+EFIAPI
+ShellGetRawCmdLine (
+  VOID
+  )
+{
+  if (mRawCmdLine == NULL) {
+return NULL;
+  } else {
+return AllocateCopyPool(StrSize(mRawCmdLine), mRawCmdLine);
+  }
+}
+
+/**
+  Function to store the raw command string.
+
+  The alias and variables have been replaced and spaces are trimmed.
+
+  @param[in] CmdLine the command line string to store.
+**/
+VOID
+EFIAPI
+ShellSetRawCmdLine (
+  IN CONST CHAR16 *CmdLine
+  )
+{
+  SHELL_FREE_NON_NULL(mRawCmdLine);
+
+  if (CmdLine != NULL) {
+//
+// The spaces in the beginning and end are trimmed.
+//
+ASSERT (*CmdLine != L' ');
+ASSERT (CmdLine[StrLen (CmdLine) - 1] != L' ');
+mRawCmdLine = AllocateCopyPool (StrSize(CmdLine), CmdLine);
+  }
+}
+
+/**
   Frees any BUFFER_LIST defined type.
 
   @param[in] List The BUFFER_LIST object to free.
-- 
2.9.0.windows.1

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

[edk2] [PATCH v3 3/5] ShellPkg: Move FindFirstCharacter/GetNextParameter to ShellCommandLib

[Ruiyu Ni]

And add Shell prefix to the two library APIs.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Application/Shell/Shell.c |  81 -
 ShellPkg/Application/Shell/Shell.h |  18 --
 .../Application/Shell/ShellParametersProtocol.c| 160 +-
 .../Application/Shell/ShellParametersProtocol.h|  29 
 ShellPkg/Include/Library/ShellCommandLib.h |  45 +
 .../UefiShellCommandLib/UefiShellCommandLib.c  | 185 +
 6 files changed, 260 insertions(+), 258 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 54ca76a..d4408b4 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -213,7 +213,7 @@ ContainsSplit(
 
   FirstQuote= FindNextInstance (CmdLine, L"\"", TRUE);
   SecondQuote   = NULL;
-  TempSpot  = FindFirstCharacter(CmdLine, L"|", L'^');
+  TempSpot  = ShellFindFirstCharacter(CmdLine, L"|", TRUE);
 
   if (FirstQuote == NULL|| 
   TempSpot == NULL  || 
@@ -236,7 +236,7 @@ ContainsSplit(
   continue;
 } else {
   FirstQuote = FindNextInstance (SecondQuote + 1, L"\"", TRUE);
-  TempSpot = FindFirstCharacter(TempSpot + 1, L"|", L'^');
+  TempSpot = ShellFindFirstCharacter(TempSpot + 1, L"|", TRUE);
   continue;
 } 
   }
@@ -716,6 +716,7 @@ FreeResources:
   }
 
   ShellFreeEnvVarList ();
+  ShellSetRawCmdLine (NULL);
 
   if (ShellCommandGetExit()) {
 return ((EFI_STATUS)ShellCommandGetExitCode());
@@ -1981,7 +1982,7 @@ IsValidSplit(
   return (EFI_OUT_OF_RESOURCES);
 }
 TempWalker = (CHAR16*)Temp;
-if (!EFI_ERROR(GetNextParameter(&TempWalker, &FirstParameter, 
StrSize(CmdLine), TRUE))) {
+if (!EFI_ERROR (ShellGetNextParameter (&TempWalker, FirstParameter, 
StrSize(CmdLine), TRUE))) {
   if (GetOperationType(FirstParameter) == Unknown_Invalid) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_SHELL_NOT_FOUND), 
ShellInfoObject.HiiHandle, FirstParameter);
 SetLastError(SHELL_NOT_FOUND);
@@ -2030,7 +2031,7 @@ VerifySplit(
   //
   // recurse to verify the next item
   //
-  TempSpot = FindFirstCharacter(CmdLine, L"|", L'^') + 1;
+  TempSpot = ShellFindFirstCharacter(CmdLine, L"|", TRUE) + 1;
   if (*TempSpot == L'a' && 
   (*(TempSpot + 1) == L' ' || *(TempSpot + 1) == CHAR_NULL)
  ) {
@@ -2147,7 +2148,7 @@ DoHelpUpdate(
 
   Walker = *CmdLine;
   while(Walker != NULL && *Walker != CHAR_NULL) {
-if (!EFI_ERROR(GetNextParameter(&Walker, &CurrentParameter, 
StrSize(*CmdLine), TRUE))) {
+if (!EFI_ERROR (ShellGetNextParameter (&Walker, CurrentParameter, 
StrSize(*CmdLine), TRUE))) {
   if (StrStr(CurrentParameter, L"-?") == CurrentParameter) {
 CurrentParameter[0] = L' ';
 CurrentParameter[1] = L' ';
@@ -2578,6 +2579,7 @@ RunShellCommand(
   CHAR16*FirstParameter;
   CHAR16*TempWalker;
   SHELL_OPERATION_TYPES Type;
+  CHAR16*OldCmdLine;
 
   ASSERT(CmdLine != NULL);
   if (StrLen(CmdLine) == 0) {
@@ -2585,11 +2587,14 @@ RunShellCommand(
   }
 
   Status  = EFI_SUCCESS;
+  FirstParameter  = NULL;
   CleanOriginal   = NULL;
+  OldCmdLine  = NULL;
 
   CleanOriginal = StrnCatGrow(&CleanOriginal, NULL, CmdLine, 0);
   if (CleanOriginal == NULL) {
-return (EFI_OUT_OF_RESOURCES);
+Status = EFI_OUT_OF_RESOURCES;
+goto Done;
   }
 
   TrimSpaces(&CleanOriginal);
@@ -2616,35 +2621,36 @@ RunShellCommand(
   // Handle case that passed in command line is just 1 or more " " characters.
   //
   if (StrLen (CleanOriginal) == 0) {
-SHELL_FREE_NON_NULL(CleanOriginal);
-return (EFI_SUCCESS);
+Status = EFI_SUCCESS;
+goto Done;
   }
 
   Status = ProcessCommandLineToFinal(&CleanOriginal);
   if (EFI_ERROR(Status)) {
-SHELL_FREE_NON_NULL(CleanOriginal);
-return (Status);
+goto Done;
   }
 
+  OldCmdLine = ShellGetRawCmdLine ();
+  ShellSetRawCmdLine (CleanOriginal);
+
   //
   // We don't do normal processing with a split command line (output from one 
command input to another)
   //
   if (ContainsSplit(CleanOriginal)) {
 Status = ProcessNewSplitCommandLine(CleanOriginal);
-SHELL_FREE_NON_NULL(CleanOriginal);
-return (Status);
-  } 
+goto Done;
+  }
 
   //
   // We need the first parameter information so we can determine the operation 
type
   //
   FirstParameter = AllocateZeroPool(StrSize(CleanOriginal));
   if (FirstParameter == NULL) {
-SHELL_FREE_NON_NULL(CleanOriginal);
-return (EFI_OUT_OF_RESOURCES);
+Status = EFI_OUT_OF_RESOURCES;
+goto Done;
   }
   TempWalker = CleanOriginal;
-  if (!EFI_ERROR(GetNextParameter(&TempWalker, &FirstParameter, 
StrSize(CleanOriginal), TRUE))) {
+  if (!EFI_ERROR (ShellGetNextParameter (&TempWalker, FirstParameter, 
StrSize(CleanOriginal), TRUE))) {
 //
 //

[edk2] [PATCH v3 1/5] ShellPkg/UefiShellCommandLib.c: Formalize EOL

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 .../UefiShellCommandLib/UefiShellCommandLib.c  | 122 ++---
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 48e4d4a..0c25528 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -1,10 +1,10 @@
 /** @file
   Provides interface to shell internal functions for shell commands.
 
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
-  (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
-
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
+  (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+
   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
@@ -1744,60 +1744,60 @@ DumpHex (
 DataSize -= Size;
   }
 }
-
-/**
-  Dump HEX data into buffer.
-   
-  @param[in] Buffer HEX data to be dumped in Buffer.
-  @param[in] Indent How many spaces to indent the output.
-  @param[in] Offset The offset of the printing.
-  @param[in] DataSize   The size in bytes of UserData.
-  @param[in] UserData   The data to print out.
-**/
-CHAR16*
-CatSDumpHex (
-  IN CHAR16  *Buffer,
-  IN UINTN   Indent,
-  IN UINTN   Offset,
-  IN UINTN   DataSize,
-  IN VOID*UserData
-  )
-{
-  UINT8   *Data;
-  UINT8   TempByte;
-  UINTN   Size;
-  UINTN   Index;
-  CHAR8   Val[50];
-  CHAR8   Str[20];
-  CHAR16  *RetVal;
-  CHAR16  *TempRetVal;
-
-  Data = UserData;
-  RetVal = Buffer;
-  while (DataSize != 0) {
-Size = 16;
-if (Size > DataSize) {
-  Size = DataSize;
-}
-
-for (Index = 0; Index < Size; Index += 1) {
-  TempByte= Data[Index];
-  Val[Index * 3 + 0]  = Hex[TempByte >> 4];
-  Val[Index * 3 + 1]  = Hex[TempByte & 0xF];
-  Val[Index * 3 + 2]  = (CHAR8) ((Index == 7) ? '-' : ' ');
-  Str[Index]  = (CHAR8) ((TempByte < ' ' || TempByte > 'z') ? '.' 
: TempByte);
-}
-
-Val[Index * 3]  = 0;
-Str[Index]  = 0;
-TempRetVal = CatSPrint (RetVal, L"%*a%08X: %-48a *%a*\r\n", Indent, "", 
Offset, Val, Str);
-SHELL_FREE_NON_NULL (RetVal);
-RetVal = TempRetVal;
-
-Data += Size;
-Offset += Size;
-DataSize -= Size;
-  }
-
-  return RetVal;
-}
+
+/**
+  Dump HEX data into buffer.
+
+  @param[in] Buffer HEX data to be dumped in Buffer.
+  @param[in] Indent How many spaces to indent the output.
+  @param[in] Offset The offset of the printing.
+  @param[in] DataSize   The size in bytes of UserData.
+  @param[in] UserData   The data to print out.
+**/
+CHAR16*
+CatSDumpHex (
+  IN CHAR16  *Buffer,
+  IN UINTN   Indent,
+  IN UINTN   Offset,
+  IN UINTN   DataSize,
+  IN VOID*UserData
+  )
+{
+  UINT8   *Data;
+  UINT8   TempByte;
+  UINTN   Size;
+  UINTN   Index;
+  CHAR8   Val[50];
+  CHAR8   Str[20];
+  CHAR16  *RetVal;
+  CHAR16  *TempRetVal;
+
+  Data = UserData;
+  RetVal = Buffer;
+  while (DataSize != 0) {
+Size = 16;
+if (Size > DataSize) {
+  Size = DataSize;
+}
+
+for (Index = 0; Index < Size; Index += 1) {
+  TempByte= Data[Index];
+  Val[Index * 3 + 0]  = Hex[TempByte >> 4];
+  Val[Index * 3 + 1]  = Hex[TempByte & 0xF];
+  Val[Index * 3 + 2]  = (CHAR8) ((Index == 7) ? '-' : ' ');
+  Str[Index]  = (CHAR8) ((TempByte < ' ' || TempByte > 'z') ? '.' 
: TempByte);
+}
+
+Val[Index * 3]  = 0;
+Str[Index]  = 0;
+TempRetVal = CatSPrint (RetVal, L"%*a%08X: %-48a *%a*\r\n", Indent, "", 
Offset, Val, Str);
+SHELL_FREE_NON_NULL (RetVal);
+RetVal = TempRetVal;
+
+Data += Size;
+Offset += Size;
+DataSize -= Size;
+  }
+
+  return RetVal;
+}
-- 
2.9.0.windows.1

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

[edk2] [PATCH v3 0/5] Fix echo to display special characters

[Ruiyu Ni]

The v3 patch splits the big v2 patch to 5 parts and adds Shell prefix
to the four new APIs exposed in ShellCommandLib.

It also changes the 2nd parameter of ShellGetNextParameter from
unnecessary CHAR16** to CHAR16*.


Ruiyu Ni (5):
  ShellPkg/UefiShellCommandLib.c: Formalize EOL
  ShellPkg/ShellCommandLib.h: Formalize EOL
  ShellPkg: Move FindFirstCharacter/GetNextParameter to ShellCommandLib
  ShellPkg: Add Shell[Get|Set]RawCmdLine to ShellCommandLib
  ShellPkg: Fix echo to support displaying special characters

 ShellPkg/Application/Shell/Shell.c |  81 ++---
 ShellPkg/Application/Shell/Shell.h |  18 --
 .../Application/Shell/ShellParametersProtocol.c| 160 +-
 .../Application/Shell/ShellParametersProtocol.h|  29 --
 ShellPkg/Include/Library/ShellCommandLib.h | 108 +--
 .../UefiShellCommandLib/UefiShellCommandLib.c  | 352 +
 ShellPkg/Library/UefiShellLevel3CommandsLib/Echo.c | 141 -
 .../UefiShellLevel3CommandsLib.uni |   3 +-
 8 files changed, 472 insertions(+), 420 deletions(-)

-- 
2.9.0.windows.1

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

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

[Paolo Bonzini]

On 16/07/2016 14:29, Laszlo Ersek wrote:
> 
> However, I recall from the thread that -Os enables -fomit-frame-pointer,
> which might make source level debugging impossible (according to the GCC
> manual).

This is only with very old debuggers.  Current debuggers use DWARF
annotations which support generation of backtraces even in the lack of a
frame pointer.

That said, the best debugging experience on recent GCC (4.8 I think) is
with -Og if you want to use it for DEBUG builds.  -O1 and -Os are
probably the best for firmware though, where code size is important.

Paolo

> Now, we're not big on source level debugging in GCC builds, at least
> right now, plus I also cannot claim that that -fomit-frame-pointer is
> never enabled *otherwise*. Much as I know -fomit-frame-pointer could be
> enabled with -O1, -O2, even with -O0?...
> 
> I'd just like to avoid a setting that *guarantees* that source level
> debugging would be impossible or garbled. Ard, can you comment on that?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Gao, Liming]

Ard:
  I understand this patch replaces Steven  patch [PATCH v2 4/7] 
BaseTools-Conf:Introduce GCC5 new toolchain for x86. So, I expect it enables 
the same functionality in IA32 & X64 to Steven patch. 

Thanks
Liming
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Monday, July 18, 2016 1:55 PM
To: Gao, Liming 
Cc: Justen, Jordan L ; edk2-devel@lists.01.org; 
af...@apple.com; Kinney, Michael D ; 
ler...@redhat.com
Subject: Re: [edk2] [RFC PATCH] BaseTools GCC: add support for GCC/X64 and 
GCC/AARCH64 in LTO mode

On 18 July 2016 at 07:46, Gao, Liming  wrote:
> Ard:
>   Yes. I will evaluate to add this support in BaseTools instead of adding 
> shell script or python script.
>
>   Besides, I also request to enable LTO for all ARCHs in new GCC5 tool chain, 
> at least IA32 and X64.
>

OK. Do you agree to enable it for both DEBUG and RELEASE (in the IA32 and X64 
case)? For ARM, I would like to keep the existing practice of having a DEBUG 
build that is suitable for single step debugging in GDB, and I am not sure yet 
how this is supposed to work under LTO, so there I only added it to RELEASE for 
now.

--
Ard.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Ard Biesheuvel
>> Sent: Monday, July 18, 2016 1:44 PM
>> To: Gao, Liming 
>> Cc: Justen, Jordan L ; 
>> edk2-devel@lists.01.org; af...@apple.com; Kinney, Michael D 
>> ; ler...@redhat.com
>> Subject: Re: [edk2] [RFC PATCH] BaseTools GCC: add support for 
>> GCC/X64 and GCC/AARCH64 in LTO mode
>>
>> On 18 July 2016 at 07:39, Gao, Liming  wrote:
>> > Ard:
>> >   I would like to enable LTO for all ARCHs in new GCC5 tool chain, 
>> > at least
>> IA32 and X64.
>> >
>> >   I like idea to reuse the same build rule. Your patch adds 
>> > lto-ld-wrapper.sh.
>> But, this doesn't work in Windows. As you know, we can build tips 
>> with GCC in windows OS.
>> (https://sourceforge.net/projects/edk2developertoolsforwindows/files)
>> . I would still support it. Have we other way to do it?
>> >
>>
>> I mentioned in the commit log that this indeed does not work on 
>> Windows. I don't use Windows, so I will not be able to test any 
>> alternatives, but I think there are two solutions possible:
>> - use a python script
>> - add support to BaseTools to translate a GNU/LD command line to a 
>> GNU/GCC command line.
>>
>> In either case, I suppose it would be implemented in python. The only 
>> difference is how to wire it up, i.e., either add it to tools_def.txt 
>> (as I have demonstrated),  or update the existing build rules for GCC 
>> to take the script into account in some way.
>>
>> Regards,
>> Ard.
>> ___
>> 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