Re: [edk2] [PATCH v2] ArmPkg/ArmV7Mmu: prefer non shareable memory on non-coherent hardware

[Ard Biesheuvel]

On 15 December 2015 at 11:28, Leif Lindholm  wrote:
> On Tue, Dec 15, 2015 at 11:10:49AM +0100, Ard Biesheuvel wrote:
>> On 8 December 2015 at 16:11, Ard Biesheuvel  
>> wrote:
>> > Commit SVN r18778 made all mappings of normal memory (inner) shareable,
>> > even on hardware that implements shareability as uncached accesses.
>> > The original concerns that prompted the change, regarding coherent DMA
>> > and virt guests migrating between CPUs, do not apply to such hardware,
>> > so revert to the original behavior in that case.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Ard Biesheuvel 
>> > ---
>> > v2: use symbolic constants for the various shift and mask values
>> > default to shareable on unexpected values, but ASSERT() as well
>> >
>>
>> Any more comment on this version? Thanks
>
> If Eugene is happy - for my part:
> Reviewed-by: Leif Lindholm 
>

Commited as SVN r19285. Thanks.


>> >  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h | 14 +++
>> >  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 42 ++--
>> >  2 files changed, 53 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h 
>> > b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
>> > index e138613ca548..cbd3d6f654a6 100644
>> > --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
>> > +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
>> > @@ -15,6 +15,20 @@
>> >  #ifndef __ARM_V7_LIB_H__
>> >  #define __ARM_V7_LIB_H__
>> >
>> > +#define ID_MMFR0_SHARELVL_SHIFT   12
>> > +#define ID_MMFR0_SHARELVL_MASK   0xf
>> > +#define ID_MMFR0_SHARELVL_ONE  0
>> > +#define ID_MMFR0_SHARELVL_TWO  1
>> > +
>> > +#define ID_MMFR0_INNERSHR_SHIFT   28
>> > +#define ID_MMFR0_INNERSHR_MASK   0xf
>> > +#define ID_MMFR0_OUTERSHR_SHIFT8
>> > +#define ID_MMFR0_OUTERSHR_MASK   0xf
>> > +
>> > +#define ID_MMFR0_SHR_IMP_UNCACHED  0
>> > +#define ID_MMFR0_SHR_IMP_HW_COHERENT   1
>> > +#define ID_MMFR0_SHR_IGNORED 0xf
>> > +
>> >  typedef VOID (*ARM_V7_CACHE_OPERATION)(UINT32);
>> >
>> >  VOID
>> > diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c 
>> > b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
>> > index 23d2e43beba0..fc8ea42843b3 100644
>> > --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
>> > +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
>> > @@ -42,6 +42,42 @@ ConvertSectionAttributesToPageAttributes (
>> >  }
>> >
>> >  STATIC
>> > +BOOLEAN
>> > +PreferNonshareableMemory (
>> > +  VOID
>> > +  )
>> > +{
>> > +  UINTN   Mmfr;
>> > +  UINTN   Val;
>> > +
>> > +  if (FeaturePcdGet (PcdNormalMemoryNonshareableOverride)) {
>> > +return TRUE;
>> > +  }
>> > +
>> > +  //
>> > +  // Check whether the innermost level of shareability (the level we will 
>> > use
>> > +  // by default to map normal memory) is implemented with hardware 
>> > coherency
>> > +  // support. Otherwise, revert to mapping as non-shareable.
>> > +  //
>> > +  Mmfr = ArmReadIdMmfr0 ();
>> > +  switch ((Mmfr >> ID_MMFR0_SHARELVL_SHIFT) & ID_MMFR0_SHARELVL_MASK) {
>> > +  case ID_MMFR0_SHARELVL_ONE:
>> > +// one level of shareability
>> > +Val = (Mmfr >> ID_MMFR0_OUTERSHR_SHIFT) & ID_MMFR0_OUTERSHR_MASK;
>> > +break;
>> > +  case ID_MMFR0_SHARELVL_TWO:
>> > +// two levels of shareability
>> > +Val = (Mmfr >> ID_MMFR0_INNERSHR_SHIFT) & ID_MMFR0_INNERSHR_MASK;
>> > +break;
>> > +  default:
>> > +// unexpected value -> shareable is the safe option
>> > +ASSERT (FALSE);
>> > +return FALSE;
>> > +  }
>> > +  return Val != ID_MMFR0_SHR_IMP_HW_COHERENT;
>> > +}
>> > +
>> > +STATIC
>> >  VOID
>> >  PopulateLevel2PageTable (
>> >IN UINT32 *SectionEntry,
>> > @@ -80,7 +116,7 @@ PopulateLevel2PageTable (
>> >break;
>> >}
>> >
>> > -  if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
>> > +  if (PreferNonshareableMemory ()) {
>> >  PageAttributes &= ~TT_DESCRIPTOR_PAGE_S_SHARED;
>> >}
>> >
>> > @@ -189,7 +225,7 @@ FillTranslationTable (
>> >break;
>> >}
>> >
>> > -  if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
>> > +  if (PreferNonshareableMemory ()) {
>> >  Attributes &= ~TT_DESCRIPTOR_SECTION_S_SHARED;
>> >}
>> >
>> > @@ -281,7 +317,7 @@ ArmConfigureMmu (
>> >}
>> >
>> >if (TTBRAttributes & TTBR_SHAREABLE) {
>> > -if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
>> > +if (PreferNonshareableMemory ()) {
>> >TTBRAttributes ^= TTBR_SHAREABLE;
>> >  } else {
>> >//
>> > --
>> > 1.9.1
>> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected

[Mahan, Patrick]

Greetings Samer,

I would like to see this patch implemented.  Part of the issue I am wrestling 
with on our AARCH64 platform is how our PCIe's are supported.  In our current 
architecture, we can have up to 6 PCIe's connected through two Switch Logic 
Interfaces (SLI) that must be programmed correctly.  Part of this is the BAR 
address that is in use which depends heavily on the BAR type.  What we are 
seeing is that the BAR type
is being demoted to 32-bit which causes us to program the SLI for 32-bit 
access.  But the PCIe device is 64-bit and attempts to use 64-bit addressing 
which fails.  

A PCD that can be configured to disable the demotion based on the presence of 
an option ROM would be greatly appreciated.  Then the code in DegradeResource() 
could simply check to see if it needed to enforce this demotion or not.

I can understand if this were a legacy BIOS image as this currently seems (to 
me) to limit option ROM drivers to be 32-bit only.

As I stated below, I currently have it commented out and this is allowing our 
SLI's to be programmed correctly.

I'll be glad to review the patch when you have it ready.

Thanks,

Patrick


From: El-Haj-Mahmoud, Samer 
Sent: Monday, December 14, 2015 3:35 PM
To: Mahan, Patrick; edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer
Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

Hello Patrick,

We ran into the same issue of automatic demoation simply because of the 
presence of an OptionROM. We believe this is an overly aggressive policy. In 
fact, I have a patch that I am about to submit that adds a platform PCD to 
enable/disable this policy.

Would like feedback on the idea as well as the patch.

Thanks,
--Samer


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mahan, 
Patrick
Sent: Monday, December 14, 2015 4:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

All,

I am working on writing the UEFI driver for our LiquidIO line of NICs and have 
run into an issue with the PCI layer that may or may not be contributing.

I am working with our AARCH64 platform, ThunderX and in the handling of the 
PCIe detection.  The code that handles the PCI configuration on ThunderX 
requires knowing the resource type of a BAR (IO16, IO32, MEM32/PMEM32, 
MEM64/PMEM64).

There is an automatic demotion of BAR types from 64-bit to 32-bit if an option 
ROM is detected.  I am trying to understand the logic behind this as I do not 
see anything in the PCIe Firmware specification (Section 5) nor the UEFI 
Specification (Section 13.4.2).  However, after inserting some debugging code 
into the PCI code under MdeModulePkg/Bus/Pci/PciBusDxe I see that my device's 
BAR goes from a
PMEM64 to a MEM32 after calling DegradeResource().

As a result, the BAR type has changed from MEM64/PMEM64 to MEM32/PMEM32 and 
this is causing some problems with properly configuring the PCI layer to handle 
devices using 64-bit PCI BARs.  I have put a PCIe Analyzer on it and I can see 
that the memory requests to the PCI device have the incorrect BAR address 
resulting in the PCI device unable to read from the host.

If I modify the call to DegradeResource() to avoid degrading the 64-bit bar to 
32-bit bar when an option ROM is detected, then 64-bit devices work correctly.

I can see if the option ROM contained a legacy image, but if it does not, or 
the option ROM is empty or disabled, then why degrade the BAR resource?

Thanks for any help understanding this,

Patrick Mahan
Cavium, Inc.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg packages

[Kinney, Michael D]

Jordan,

Reponses included below.

1) edk2: Maintainers.txt patch email sent.
2) Thank you very much for ack and detailed review/feedback in Quark*Pkgs
3) I have fixed all the items for the edk2-non-osi repository and pushed them 
to:
 
https://github.com/mdkinney/edk2-non-osi.git

Can you create the new edk2-non-osi repository on tianocore and import this 
content?

Thanks,

Mike


> -Original Message-
> From: Justen, Jordan L
> Sent: Monday, December 14, 2015 11:47 PM
> To: Kinney, Michael D ; edk2-
> de...@lists.01.org (edk2-devel@lists.01.org)  de...@lists.01.org>
> Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> packages
> 
> On 2015-12-13 14:48:54, Kinney, Michael D wrote:
> > Jordan,
> >
> > I have updated to Quark_V3 that uses this concept along with a
> > proposed edk2-non-osi repository with a new QuarkSocBinPkg. It
> uses
> > PACKAGES_PATH to support the multiple repositories to do a
> build.
> > The content is posted for review on GitHub.
> >
> > The QuarkSocPkg and QuarkPlatformPkg are in branch Quark_V3 on
> GitHub at:
> >
> > https://github.com/mdkinney/edk2.git
> >
> > The edk2-non-iso repository with the QuarkSocBinPkg is on
> GitHub at:
> >
> > https://github.com/mdkinney/edk2-non-osi.git
> >
> > Here are the instructions I use to clone the content and set
> > environment variables to perform platform builds.
> >
> >
> 
> ==
> > git clone https://github.com/mdkinney/edk2.git --branch
> Quark_V3
> 
> I notice that this file doesn't have the standard copyright
> header:
> 
> QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLibModStrs.un
> i
> 
> I found this with:
> 
> $ git grep -L 'http://opensource.org/licenses/bsd-license.php'
> Quark*
> 

Thanks.  I have fixed this.

> Also, QuarkPlatformPkg/License.txt and QuarkSocPkg/License.txt
> are
> using unix line endings. How about copying MdePkg/License.txt
> directly?
> 
> I found this with:
> 
> $ md5sum */License.txt
> 

I found these 2 license files yesterday with wrong line endings.  I have fixed 
them.
I also found a C source file with a Unicode '-' character in it, and I fixed 
that too.

> With these fixed:
> 
> Acked-by: Jordan Justen 
> 
> So, I guess these probably two changes are ready to commit,
> right?

Thank you very much for the detailed reviews and feedback.
Yes.  I am ready to commit these two packages.

> 
> * QuarkPlatformPkg: Add new package for Galileo boards
> * QuarkSocPkg: Add new package for Quark SoC X1000
> 
> Can you send out a patch for the Maintainers.txt?

Yes.  I have sent patch review email.

> 
> > git clone https://github.com/tianocore/edk2-FatPkg.git FatPkg
> > git clone https://github.com/mdkinney/edk2-non-osi.git
> 
> I also reviewed the updated edk2-non-osi tree with
> 5573e513dfb88f96c8ae08471e369c335a540a37 "QuarkSocBinPkg:
> Reformat
> IntelProprietaryLicense.txt". I think you should just squash
> that into
> the previous commit.

Done

> 
> Also, in:
> 
> In QuarkSocBinPkg/License.txt
> 
> You have this text:
> 
> > Additional terms:
> > -
> >
> QuarkSocBinPkg\QuarkNorthCluster\Binary\QuarkMicrocode\IntelProp
> rietaryLicense.txt
> 
> This sounds similar to the FAT driver, where all of the content
> has
> BSD + and additional term. But, in this case, the license only
> applies
> to 1 file. How about something like what we have in
> OvmfPkg/License.txt? For example:
> 
> > Some files are subject to a license documented in the
> > IntelProprietaryLicense.txt file. These files are in the same
> > directory as IntelProprietaryLicense.txt, and they do not have
> a
> > license specified within the file.

Done

> 
> -Jordan
> 
> > git clone https://github.com/tianocore/edk2-BaseTools-
> win32.git
> >
> > set WORKSPACE=%CD%
> > set PACKAGES_PATH=%WORKSPACE%\edk2;%WORKSPACE%\edk2-non-osi
> > set EDK_TOOLS_BIN=%WORKSPACE%\edk2-BaseTools-win32
> >
> > cd edk2
> >
> > edkSetup.bat
> >
> > build -a IA32 -t VS2015x86 -p QuarkPlatformPkg/Quark.dsc
> > build -a IA32 -t VS2015x86 -p QuarkPlatformPkg/QuarkMin.dsc
> >
> 
> =
> >
> > commit 613f0f5ff082d85e02403eddefdc1d54138663c5
> > Author: Michael Kinney 
> > Date:   Tue Nov 24 23:43:40 2015 -0800
> >
> > QuarkPlatformPkg: Add new package for Galileo boards
> >
> > Changes for V3
> > 1) Set PcdResetOnMemoryTypeInformationChange FALSE in
> QuarkMin.dsc
> > This is required because QuarkMin.dsc uses the emulated
> variable
> > driver that does not preserve any non-volatile UEFI
> variables
> > across reset.  If the condition is met where the memory
> type
> > information variable needs to be updated, then the system
> will reset
> > every time the UEFI Shell is run.  By setting this PCD to
> FALSE,
> > then reset action is disabled.
> > 2) Move one 

Re: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg packages

[Jordan Justen]

On 2015-12-15 09:54:25, Kinney, Michael D wrote:
> Jordan,
> 
> Reponses included below.
> 
> 1) edk2: Maintainers.txt patch email sent.
> 2) Thank you very much for ack and detailed review/feedback in Quark*Pkgs
> 3) I have fixed all the items for the edk2-non-osi repository and pushed them 
> to:
>  
> https://github.com/mdkinney/edk2-non-osi.git
> 
> Can you create the new edk2-non-osi repository on tianocore and
> import this content?
> 

I pushed your branch to:

https://github.com/tianocore/edk2-non-osi

I guess this is our first repo where the upstream is git rather than
svn...

-Jordan

> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Monday, December 14, 2015 11:47 PM
> > To: Kinney, Michael D ; edk2-
> > de...@lists.01.org (edk2-devel@lists.01.org)  > de...@lists.01.org>
> > Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> > packages
> > 
> > On 2015-12-13 14:48:54, Kinney, Michael D wrote:
> > > Jordan,
> > >
> > > I have updated to Quark_V3 that uses this concept along with a
> > > proposed edk2-non-osi repository with a new QuarkSocBinPkg. It
> > uses
> > > PACKAGES_PATH to support the multiple repositories to do a
> > build.
> > > The content is posted for review on GitHub.
> > >
> > > The QuarkSocPkg and QuarkPlatformPkg are in branch Quark_V3 on
> > GitHub at:
> > >
> > > https://github.com/mdkinney/edk2.git
> > >
> > > The edk2-non-iso repository with the QuarkSocBinPkg is on
> > GitHub at:
> > >
> > > https://github.com/mdkinney/edk2-non-osi.git
> > >
> > > Here are the instructions I use to clone the content and set
> > > environment variables to perform platform builds.
> > >
> > >
> > 
> > ==
> > > git clone https://github.com/mdkinney/edk2.git --branch
> > Quark_V3
> > 
> > I notice that this file doesn't have the standard copyright
> > header:
> > 
> > QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLibModStrs.un
> > i
> > 
> > I found this with:
> > 
> > $ git grep -L 'http://opensource.org/licenses/bsd-license.php'
> > Quark*
> > 
> 
> Thanks.  I have fixed this.
> 
> > Also, QuarkPlatformPkg/License.txt and QuarkSocPkg/License.txt
> > are
> > using unix line endings. How about copying MdePkg/License.txt
> > directly?
> > 
> > I found this with:
> > 
> > $ md5sum */License.txt
> > 
> 
> I found these 2 license files yesterday with wrong line endings.  I have 
> fixed them.
> I also found a C source file with a Unicode '-' character in it, and I fixed 
> that too.
> 
> > With these fixed:
> > 
> > Acked-by: Jordan Justen 
> > 
> > So, I guess these probably two changes are ready to commit,
> > right?
> 
> Thank you very much for the detailed reviews and feedback.
> Yes.  I am ready to commit these two packages.
> 
> > 
> > * QuarkPlatformPkg: Add new package for Galileo boards
> > * QuarkSocPkg: Add new package for Quark SoC X1000
> > 
> > Can you send out a patch for the Maintainers.txt?
> 
> Yes.  I have sent patch review email.
> 
> > 
> > > git clone https://github.com/tianocore/edk2-FatPkg.git FatPkg
> > > git clone https://github.com/mdkinney/edk2-non-osi.git
> > 
> > I also reviewed the updated edk2-non-osi tree with
> > 5573e513dfb88f96c8ae08471e369c335a540a37 "QuarkSocBinPkg:
> > Reformat
> > IntelProprietaryLicense.txt". I think you should just squash
> > that into
> > the previous commit.
> 
> Done
> 
> > 
> > Also, in:
> > 
> > In QuarkSocBinPkg/License.txt
> > 
> > You have this text:
> > 
> > > Additional terms:
> > > -
> > >
> > QuarkSocBinPkg\QuarkNorthCluster\Binary\QuarkMicrocode\IntelProp
> > rietaryLicense.txt
> > 
> > This sounds similar to the FAT driver, where all of the content
> > has
> > BSD + and additional term. But, in this case, the license only
> > applies
> > to 1 file. How about something like what we have in
> > OvmfPkg/License.txt? For example:
> > 
> > > Some files are subject to a license documented in the
> > > IntelProprietaryLicense.txt file. These files are in the same
> > > directory as IntelProprietaryLicense.txt, and they do not have
> > a
> > > license specified within the file.
> 
> Done
> 
> > 
> > -Jordan
> > 
> > > git clone https://github.com/tianocore/edk2-BaseTools-
> > win32.git
> > >
> > > set WORKSPACE=%CD%
> > > set PACKAGES_PATH=%WORKSPACE%\edk2;%WORKSPACE%\edk2-non-osi
> > > set EDK_TOOLS_BIN=%WORKSPACE%\edk2-BaseTools-win32
> > >
> > > cd edk2
> > >
> > > edkSetup.bat
> > >
> > > build -a IA32 -t VS2015x86 -p QuarkPlatformPkg/Quark.dsc
> > > build -a IA32 -t VS2015x86 -p QuarkPlatformPkg/QuarkMin.dsc
> > >
> > 
> > =
> > >
> > > commit 613f0f5ff082d85e02403eddefdc1d54138663c5
> > > Author: Michael Kinney 
> > > Date:   Tue Nov 24 23:43:40 2015 -0800
> > >
> > > QuarkPlatformPkg: Add new package for Galileo boards
> > >
> > 

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[M.V.R. Ravikanth]

Ok.I understand!
I did implement new and delete API's for EFi and they are working fine now.Now 
I am getting below linker errors which I am not sure how to resolve them.Do we 
have any specific compiler flags for disabling these errors or I have to define 
them in my code?
Linker errors: 1.undefined reference to `__cxa_atexit' 2.undefined reference to 
`__cxa_pure_virtual'
Regards,Ravi
> Date: Tue, 15 Dec 2015 08:36:34 +0100
> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> From: ard.biesheu...@linaro.org
> To: mvrravika...@live.com
> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> 
> On 15 December 2015 at 04:16, M.V.R. Ravikanth  wrote:
> > Thanks for the information Andrew!
> >
> > So,I have to re write the entire standard library code which is in line with
> > EFI environment such as AllocatePool?If yes,then it would a big task at
> > hand.If no,will the recompilation of standard libraries in EFI environment
> > suffice here?
> >
> 
> No. The C++ runtime is tightly coupled to the C library, which in turn
> is tightly coupled to the OS.
> 
> It does depend on what C++ features you need: exception support will
> be problematic, I guess, but simply implementing new and delete should
> not be that difficult.
> 
> > Also,when I compiled my CPP code with Visual studio/WinDDK compiler in UDK
> > environment,I did not re write the standard library inline with EFI
> > environment.But the efi image was built and executed without any errors.Now
> > I am not sure how.
> >
> > Thanks again for all your support !
> > 
> > From: Andrew Fish
> > Sent: ‎15-‎12-‎2015 04:28
> > To: M.V.R. Ravikanth
> > Cc: Ard Biesheuvel; edk2-devel@lists.01.org; Gao, Liming
> >
> > Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >
> >
> >> On Dec 14, 2015, at 10:44 AM, M.V.R. Ravikanth 
> >> wrote:
> >>
> >> Oh Ok great!Thanks :)
> >> Now I actually removed the --emit-relocs linker option and GenFw did not
> >> give me any issues.Does this mean that my final EFI binary has issues but
> >> GenFw did not report them
> >
> > The PE/COFF images that created for EFI need to be relocatable. If they are
> > not relocatable they can only be loaded at thier linked address which is
> > usually zero (or some place close to that). The ELF relocations get
> > converted to PE/COFF relocations. When your application gets loaded memory
> > is allocated and your application is relocated to run at that new address.
> > So it is likely that you broke something by turning off --emit-relocs.
> >
> >> (this case is with standard libraries linked and my CPP program has
> >> reference to standard libraries)?
> >>
> >
> > I still think you are confused about Ard's comment about using the C++
> > runtime/standard libs. When your C++ code invokes new and delete what makes
> > you think the Linux C++ runtime knows how to call gBS->AllocatePool()? The
> > Linux C++ standard lib is going to make Linux system calls which will most
> > like crash in EFI. Likewise your Linux C++ runtime is not going to run
> > properly on Windows.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >> -Ravi
> >>> Date: Mon, 14 Dec 2015 19:37:50 +0100
> >>> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >>> From: ard.biesheu...@linaro.org
> >>> To: mvrravika...@live.com
> >>> CC: af...@apple.com; liming@intel.com; edk2-devel@lists.01.org
> >>>
> >>> On 14 December 2015 at 19:24, M.V.R. Ravikanth 
> >>> wrote:
>  Below are the detailed steps which I perform:
> 
>  1.Compile CPP program with linaro GCC on windows.
>  2.Linking
>    ->If my code contains reference to standard C++ libraries,then I
>  include the libstdc++ and dependent libraries.In this case,I see the
>  GenFw
>  relocation errors.
>    ->If my code DOESN'T contain reference to standard c++
>  libraries,then
>  I DO NOT include the libstd++ and dependent libraries and in this case,I
>  DO
>  NOT see "GenFw" relocation erros.
> 
>  Also,I am including the static standard libraries such as stdc++,c, and
>  gcc
>  which comes as part of the linaro toolchain.So,Does this mean that
>  standard
>  libraries are built with small memory model and that is the reason I am
>  seeing the relocation errors?
> 
> >>>
> >>> OK, that is the culprit right there. You need to rebuild your C++
> >>> runtime, but perhaps it is even better to reimplement the bits that
> >>> you need in a new library that can be built with -fno-exceptions,
> >>> since using the plain C++ runtime is probably not a good idea.
> >>>
>  
>  From: mvrravika...@live.com
>  To: ard.biesheu...@linaro.org; af...@apple.com
>  CC: liming@intel.com; edk2-devel@lists.01.org
>  Subject: RE: [edk2] GenFW Error 3000 Invalid 

Re: [edk2] [PATCH] ArmPkg/CpuDxe: drop ARMv4 exception handling code

[Leif Lindholm]

On Tue, Dec 15, 2015 at 10:47:56AM +0100, Ard Biesheuvel wrote:
> Since we do not support anything below ARMv7, let's promote the ARMv6
> exception handling code in CpuDxe to the only version we provide for
> ARM. This means we can drop the unused ARMv4 version.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Thanks!
Reviewed-by: Leif Lindholm 

> ---
>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/Exception.c  |   0
>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/ExceptionSupport.S   |   0
>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/ExceptionSupport.asm |   0
>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/Mmu.c|   0
>  ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S| 191 
> 
>  ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.asm  | 152 
> 
>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf  |  18 +-
>  7 files changed, 4 insertions(+), 357 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c 
> b/ArmPkg/Drivers/CpuDxe/Arm/Exception.c
> similarity index 100%
> rename from ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
> rename to ArmPkg/Drivers/CpuDxe/Arm/Exception.c
> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.S 
> b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
> similarity index 100%
> rename from ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.S
> rename to ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm 
> b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.asm
> similarity index 100%
> rename from ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm
> rename to ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.asm
> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Mmu.c 
> b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> similarity index 100%
> rename from ArmPkg/Drivers/CpuDxe/ArmV6/Mmu.c
> rename to ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S 
> b/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S
> deleted file mode 100644
> index c82618aa1bc9..
> --- a/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S
> +++ /dev/null
> @@ -1,191 +0,0 @@
> -#--
> -#
> -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
> -#
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD 
> License
> -# which accompanies this distribution.  The full text of the license may be 
> found at
> -# http://opensource.org/licenses/bsd-license.php
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -#
> -#--
> -
> -.text
> -.align 3
> -
> -GCC_ASM_EXPORT(ExceptionHandlersStart)
> -GCC_ASM_EXPORT(ExceptionHandlersEnd)
> -GCC_ASM_EXPORT(CommonExceptionEntry)
> -GCC_ASM_EXPORT(AsmCommonExceptionEntry)
> -GCC_ASM_EXPORT(CommonCExceptionHandler)
> -
> -ASM_PFX(ExceptionHandlersStart):
> -
> -ASM_PFX(Reset):
> -  b ASM_PFX(ResetEntry)
> -
> -ASM_PFX(UndefinedInstruction):
> -  b ASM_PFX(UndefinedInstructionEntry)
> -
> -ASM_PFX(SoftwareInterrupt):
> -  b ASM_PFX(SoftwareInterruptEntry)
> -
> -ASM_PFX(PrefetchAbort):
> -  b ASM_PFX(PrefetchAbortEntry)
> -
> -ASM_PFX(DataAbort):
> -  b ASM_PFX(DataAbortEntry)
> -
> -ASM_PFX(ReservedException):
> -  b ASM_PFX(ReservedExceptionEntry)
> -
> -ASM_PFX(Irq):
> -  b ASM_PFX(IrqEntry)
> -
> -ASM_PFX(Fiq):
> -  b ASM_PFX(FiqEntry)
> -
> -ASM_PFX(ResetEntry):
> -  srsdb #0x13!@ Store return state on SVC stack
> -  stmfd SP!,{LR}  @ Store the link register for the 
> current mode
> -  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - 
> CPSR
> -  stmfd SP!,{R0-R12}  @ Store the register state
> -
> -  mov   R0,#0
> -  ldr   R1,ASM_PFX(CommonExceptionEntry)
> -  bxR1
> -
> -ASM_PFX(UndefinedInstructionEntry):
> -  srsdb #0x13!@ Store return state on SVC stack
> -  cps   #0x13 @ Switch to SVC for common stack
> -  stmfd SP!,{LR}  @ Store the link register for the 
> current mode
> -  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - 
> CPSR
> -  stmfd SP!,{R0-R12}  @ Store the register state
> -
> -  mov   r0,#1
> -  ldr   r1,ASM_PFX(CommonExceptionEntry)
> -  bxr1
> -
> -ASM_PFX(SoftwareInterruptEntry):
> -  srsdb #0x13!@ Store return state on SVC stack
> -  stmfd SP!,{LR}  @ Store the link register for the 
> current mode
> -  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - 
> CPSR
> -  stmfd SP!,{R0-R12}  

Re: [edk2] [PATCH] ArmPkg/CpuDxe: drop ARMv4 exception handling code

[Ard Biesheuvel]

On 15 December 2015 at 10:51, Leif Lindholm  wrote:
> On Tue, Dec 15, 2015 at 10:47:56AM +0100, Ard Biesheuvel wrote:
>> Since we do not support anything below ARMv7, let's promote the ARMv6
>> exception handling code in CpuDxe to the only version we provide for
>> ARM. This means we can drop the unused ARMv4 version.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>
> Thanks!
> Reviewed-by: Leif Lindholm 
>

Committed as SVN r19273

>> ---
>>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/Exception.c  |   0
>>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/ExceptionSupport.S   |   0
>>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/ExceptionSupport.asm |   0
>>  ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/Mmu.c|   0
>>  ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S| 191 
>> 
>>  ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.asm  | 152 
>> 
>>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf  |  18 +-
>>  7 files changed, 4 insertions(+), 357 deletions(-)
>>
>> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c 
>> b/ArmPkg/Drivers/CpuDxe/Arm/Exception.c
>> similarity index 100%
>> rename from ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
>> rename to ArmPkg/Drivers/CpuDxe/Arm/Exception.c
>> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.S 
>> b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
>> similarity index 100%
>> rename from ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.S
>> rename to ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
>> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm 
>> b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.asm
>> similarity index 100%
>> rename from ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm
>> rename to ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.asm
>> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Mmu.c 
>> b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
>> similarity index 100%
>> rename from ArmPkg/Drivers/CpuDxe/ArmV6/Mmu.c
>> rename to ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
>> diff --git a/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S 
>> b/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S
>> deleted file mode 100644
>> index c82618aa1bc9..
>> --- a/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S
>> +++ /dev/null
>> @@ -1,191 +0,0 @@
>> -#--
>> -#
>> -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
>> -#
>> -# This program and the accompanying materials
>> -# are licensed and made available under the terms and conditions of the BSD 
>> License
>> -# which accompanies this distribution.  The full text of the license may be 
>> found at
>> -# http://opensource.org/licenses/bsd-license.php
>> -#
>> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> -#
>> -#--
>> -
>> -.text
>> -.align 3
>> -
>> -GCC_ASM_EXPORT(ExceptionHandlersStart)
>> -GCC_ASM_EXPORT(ExceptionHandlersEnd)
>> -GCC_ASM_EXPORT(CommonExceptionEntry)
>> -GCC_ASM_EXPORT(AsmCommonExceptionEntry)
>> -GCC_ASM_EXPORT(CommonCExceptionHandler)
>> -
>> -ASM_PFX(ExceptionHandlersStart):
>> -
>> -ASM_PFX(Reset):
>> -  b ASM_PFX(ResetEntry)
>> -
>> -ASM_PFX(UndefinedInstruction):
>> -  b ASM_PFX(UndefinedInstructionEntry)
>> -
>> -ASM_PFX(SoftwareInterrupt):
>> -  b ASM_PFX(SoftwareInterruptEntry)
>> -
>> -ASM_PFX(PrefetchAbort):
>> -  b ASM_PFX(PrefetchAbortEntry)
>> -
>> -ASM_PFX(DataAbort):
>> -  b ASM_PFX(DataAbortEntry)
>> -
>> -ASM_PFX(ReservedException):
>> -  b ASM_PFX(ReservedExceptionEntry)
>> -
>> -ASM_PFX(Irq):
>> -  b ASM_PFX(IrqEntry)
>> -
>> -ASM_PFX(Fiq):
>> -  b ASM_PFX(FiqEntry)
>> -
>> -ASM_PFX(ResetEntry):
>> -  srsdb #0x13!@ Store return state on SVC stack
>> -  stmfd SP!,{LR}  @ Store the link register for the 
>> current mode
>> -  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - 
>> CPSR
>> -  stmfd SP!,{R0-R12}  @ Store the register state
>> -
>> -  mov   R0,#0
>> -  ldr   R1,ASM_PFX(CommonExceptionEntry)
>> -  bxR1
>> -
>> -ASM_PFX(UndefinedInstructionEntry):
>> -  srsdb #0x13!@ Store return state on SVC stack
>> -  cps   #0x13 @ Switch to SVC for common stack
>> -  stmfd SP!,{LR}  @ Store the link register for the 
>> current mode
>> -  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - 
>> CPSR
>> -  stmfd SP!,{R0-R12}  @ Store the register state
>> -
>> -  mov   r0,#1
>> -  ldr   r1,ASM_PFX(CommonExceptionEntry)
>> -  bxr1
>> -
>> -ASM_PFX(SoftwareInterruptEntry):
>> -  srsdb #0x13!@ Store return 

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[Ard Biesheuvel]

On 15 December 2015 at 11:06, M.V.R. Ravikanth  wrote:
> Yes.I am using -fno-rtti.So you want me to remove this flag?
>

No, you should keep it. As I said, things like exceptions and RTTI
will make your job a lot more difficult. I was just curious whether
you could get rid of the call to __cxa_pure_virtual() by disabling
RTTI, but you have already done so.

-- 
Ard.

>> Date: Tue, 15 Dec 2015 10:41:15 +0100
>
>> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
>> From: ard.biesheu...@linaro.org
>> To: mvrravika...@live.com
>> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
>>
>> On 15 December 2015 at 10:07, M.V.R. Ravikanth 
>> wrote:
>> > Ok.I understand!
>> >
>> > I did implement new and delete API's for EFi and they are working fine
>> > now.Now I am getting below linker errors which I am not sure how to
>> > resolve
>> > them.Do we have any specific compiler flags for disabling these errors
>> > or I
>> > have to define them in my code?
>> >
>> > Linker errors:
>> > 1.undefined reference to `__cxa_atexit'
>>
>> This is used to register destructors of global objects. If you don't
>> have any such objects, you can simply define it as a function that
>> does nothing. Note that if you do have such objects, you need to
>> ensure that their constructors are called, i.e., you will need to
>> define a EDK2 style constructor in your C++ runtime library that calls
>> all the global object constructors in turn.
>>
>> > 2.undefined reference to `__cxa_pure_virtual'
>> >
>>
>> You can simply implement this as ASSERT(FALSE) since it is something
>> that should never happen.
>>
>> Are you using -fno-rtti?
>>
>> --
>> Ard.
>>
>> >
>> >> Date: Tue, 15 Dec 2015 08:36:34 +0100
>> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
>> >> errors
>> >> From: ard.biesheu...@linaro.org
>> >> To: mvrravika...@live.com
>> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
>> >
>> >>
>> >> On 15 December 2015 at 04:16, M.V.R. Ravikanth 
>> >> wrote:
>> >> > Thanks for the information Andrew!
>> >> >
>> >> > So,I have to re write the entire standard library code which is in
>> >> > line
>> >> > with
>> >> > EFI environment such as AllocatePool?If yes,then it would a big task
>> >> > at
>> >> > hand.If no,will the recompilation of standard libraries in EFI
>> >> > environment
>> >> > suffice here?
>> >> >
>> >>
>> >> No. The C++ runtime is tightly coupled to the C library, which in turn
>> >> is tightly coupled to the OS.
>> >>
>> >> It does depend on what C++ features you need: exception support will
>> >> be problematic, I guess, but simply implementing new and delete should
>> >> not be that difficult.
>> >>
>> >> > Also,when I compiled my CPP code with Visual studio/WinDDK compiler
>> >> > in
>> >> > UDK
>> >> > environment,I did not re write the standard library inline with EFI
>> >> > environment.But the efi image was built and executed without any
>> >> > errors.Now
>> >> > I am not sure how.
>> >> >
>> >> > Thanks again for all your support !
>> >> > 
>> >> > From: Andrew Fish
>> >> > Sent: ‎15-‎12-‎2015 04:28
>> >> > To: M.V.R. Ravikanth
>> >> > Cc: Ard Biesheuvel; edk2-devel@lists.01.org; Gao, Liming
>> >> >
>> >> > Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
>> >> > errors
>> >> >
>> >> >
>> >> >> On Dec 14, 2015, at 10:44 AM, M.V.R. Ravikanth
>> >> >> 
>> >> >> wrote:
>> >> >>
>> >> >> Oh Ok great!Thanks :)
>> >> >> Now I actually removed the --emit-relocs linker option and GenFw did
>> >> >> not
>> >> >> give me any issues.Does this mean that my final EFI binary has
>> >> >> issues
>> >> >> but
>> >> >> GenFw did not report them
>> >> >
>> >> > The PE/COFF images that created for EFI need to be relocatable. If
>> >> > they
>> >> > are
>> >> > not relocatable they can only be loaded at thier linked address which
>> >> > is
>> >> > usually zero (or some place close to that). The ELF relocations get
>> >> > converted to PE/COFF relocations. When your application gets loaded
>> >> > memory
>> >> > is allocated and your application is relocated to run at that new
>> >> > address.
>> >> > So it is likely that you broke something by turning off
>> >> > --emit-relocs.
>> >> >
>> >> >> (this case is with standard libraries linked and my CPP program has
>> >> >> reference to standard libraries)?
>> >> >>
>> >> >
>> >> > I still think you are confused about Ard's comment about using the
>> >> > C++
>> >> > runtime/standard libs. When your C++ code invokes new and delete what
>> >> > makes
>> >> > you think the Linux C++ runtime knows how to call
>> >> > gBS->AllocatePool()?
>> >> > The
>> >> > Linux C++ standard lib is going to make Linux system calls which will
>> >> > most
>> >> > like crash in EFI. Likewise your Linux C++ runtime is not going to
>> >> > run
>> >> > properly on Windows.
>> >> >
>> >> > 

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[Ard Biesheuvel]

On 15 December 2015 at 10:07, M.V.R. Ravikanth  wrote:
> Ok.I understand!
>
> I did implement new and delete API's for EFi and they are working fine
> now.Now I am getting below linker errors which I am not sure how to resolve
> them.Do we have any specific compiler flags for disabling these errors or I
> have to define them in my code?
>
> Linker errors:
>  1.undefined reference to `__cxa_atexit'

This is used to register destructors of global objects. If you don't
have any such objects, you can simply define it as a function that
does nothing. Note that if you do have such objects, you need to
ensure that their constructors are called, i.e., you will need to
define a EDK2 style constructor in your C++ runtime library that calls
all the global object constructors in turn.

>  2.undefined reference to `__cxa_pure_virtual'
>

You can simply implement this as ASSERT(FALSE) since it is something
that should never happen.

Are you using -fno-rtti?

-- 
Ard.

>
>> Date: Tue, 15 Dec 2015 08:36:34 +0100
>> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
>> From: ard.biesheu...@linaro.org
>> To: mvrravika...@live.com
>> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
>
>>
>> On 15 December 2015 at 04:16, M.V.R. Ravikanth 
>> wrote:
>> > Thanks for the information Andrew!
>> >
>> > So,I have to re write the entire standard library code which is in line
>> > with
>> > EFI environment such as AllocatePool?If yes,then it would a big task at
>> > hand.If no,will the recompilation of standard libraries in EFI
>> > environment
>> > suffice here?
>> >
>>
>> No. The C++ runtime is tightly coupled to the C library, which in turn
>> is tightly coupled to the OS.
>>
>> It does depend on what C++ features you need: exception support will
>> be problematic, I guess, but simply implementing new and delete should
>> not be that difficult.
>>
>> > Also,when I compiled my CPP code with Visual studio/WinDDK compiler in
>> > UDK
>> > environment,I did not re write the standard library inline with EFI
>> > environment.But the efi image was built and executed without any
>> > errors.Now
>> > I am not sure how.
>> >
>> > Thanks again for all your support !
>> > 
>> > From: Andrew Fish
>> > Sent: ‎15-‎12-‎2015 04:28
>> > To: M.V.R. Ravikanth
>> > Cc: Ard Biesheuvel; edk2-devel@lists.01.org; Gao, Liming
>> >
>> > Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
>> >
>> >
>> >> On Dec 14, 2015, at 10:44 AM, M.V.R. Ravikanth 
>> >> wrote:
>> >>
>> >> Oh Ok great!Thanks :)
>> >> Now I actually removed the --emit-relocs linker option and GenFw did
>> >> not
>> >> give me any issues.Does this mean that my final EFI binary has issues
>> >> but
>> >> GenFw did not report them
>> >
>> > The PE/COFF images that created for EFI need to be relocatable. If they
>> > are
>> > not relocatable they can only be loaded at thier linked address which is
>> > usually zero (or some place close to that). The ELF relocations get
>> > converted to PE/COFF relocations. When your application gets loaded
>> > memory
>> > is allocated and your application is relocated to run at that new
>> > address.
>> > So it is likely that you broke something by turning off --emit-relocs.
>> >
>> >> (this case is with standard libraries linked and my CPP program has
>> >> reference to standard libraries)?
>> >>
>> >
>> > I still think you are confused about Ard's comment about using the C++
>> > runtime/standard libs. When your C++ code invokes new and delete what
>> > makes
>> > you think the Linux C++ runtime knows how to call gBS->AllocatePool()?
>> > The
>> > Linux C++ standard lib is going to make Linux system calls which will
>> > most
>> > like crash in EFI. Likewise your Linux C++ runtime is not going to run
>> > properly on Windows.
>> >
>> > Thanks,
>> >
>> > Andrew Fish
>> >
>> >> -Ravi
>> >>> Date: Mon, 14 Dec 2015 19:37:50 +0100
>> >>> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
>> >>> errors
>> >>> From: ard.biesheu...@linaro.org
>> >>> To: mvrravika...@live.com
>> >>> CC: af...@apple.com; liming@intel.com; edk2-devel@lists.01.org
>> >>>
>> >>> On 14 December 2015 at 19:24, M.V.R. Ravikanth 
>> >>> wrote:
>>  Below are the detailed steps which I perform:
>> 
>>  1.Compile CPP program with linaro GCC on windows.
>>  2.Linking
>>  ->If my code contains reference to standard C++ libraries,then I
>>  include the libstdc++ and dependent libraries.In this case,I see the
>>  GenFw
>>  relocation errors.
>>  ->If my code DOESN'T contain reference to standard c++
>>  libraries,then
>>  I DO NOT include the libstd++ and dependent libraries and in this
>>  case,I
>>  DO
>>  NOT see "GenFw" relocation erros.
>> 
>>  Also,I am including the static standard libraries such as stdc++,c,
>>  and
>> 

[edk2] [PATCH] ArmPkg/CpuDxe: drop ARMv4 exception handling code

[Ard Biesheuvel]

Since we do not support anything below ARMv7, let's promote the ARMv6
exception handling code in CpuDxe to the only version we provide for
ARM. This means we can drop the unused ARMv4 version.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/Exception.c  |   0
 ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/ExceptionSupport.S   |   0
 ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/ExceptionSupport.asm |   0
 ArmPkg/Drivers/CpuDxe/{ArmV6 => Arm}/Mmu.c|   0
 ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S| 191 

 ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.asm  | 152 

 ArmPkg/Drivers/CpuDxe/CpuDxe.inf  |  18 +-
 7 files changed, 4 insertions(+), 357 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c 
b/ArmPkg/Drivers/CpuDxe/Arm/Exception.c
similarity index 100%
rename from ArmPkg/Drivers/CpuDxe/ArmV6/Exception.c
rename to ArmPkg/Drivers/CpuDxe/Arm/Exception.c
diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.S 
b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
similarity index 100%
rename from ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.S
rename to ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm 
b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.asm
similarity index 100%
rename from ArmPkg/Drivers/CpuDxe/ArmV6/ExceptionSupport.asm
rename to ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.asm
diff --git a/ArmPkg/Drivers/CpuDxe/ArmV6/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
similarity index 100%
rename from ArmPkg/Drivers/CpuDxe/ArmV6/Mmu.c
rename to ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
diff --git a/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S 
b/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S
deleted file mode 100644
index c82618aa1bc9..
--- a/ArmPkg/Drivers/CpuDxe/ArmV4/ExceptionSupport.S
+++ /dev/null
@@ -1,191 +0,0 @@
-#--
-#
-# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
-#
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD 
License
-# which accompanies this distribution.  The full text of the license may be 
found at
-# http://opensource.org/licenses/bsd-license.php
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-#
-#--
-
-.text
-.align 3
-
-GCC_ASM_EXPORT(ExceptionHandlersStart)
-GCC_ASM_EXPORT(ExceptionHandlersEnd)
-GCC_ASM_EXPORT(CommonExceptionEntry)
-GCC_ASM_EXPORT(AsmCommonExceptionEntry)
-GCC_ASM_EXPORT(CommonCExceptionHandler)
-
-ASM_PFX(ExceptionHandlersStart):
-
-ASM_PFX(Reset):
-  b ASM_PFX(ResetEntry)
-
-ASM_PFX(UndefinedInstruction):
-  b ASM_PFX(UndefinedInstructionEntry)
-
-ASM_PFX(SoftwareInterrupt):
-  b ASM_PFX(SoftwareInterruptEntry)
-
-ASM_PFX(PrefetchAbort):
-  b ASM_PFX(PrefetchAbortEntry)
-
-ASM_PFX(DataAbort):
-  b ASM_PFX(DataAbortEntry)
-
-ASM_PFX(ReservedException):
-  b ASM_PFX(ReservedExceptionEntry)
-
-ASM_PFX(Irq):
-  b ASM_PFX(IrqEntry)
-
-ASM_PFX(Fiq):
-  b ASM_PFX(FiqEntry)
-
-ASM_PFX(ResetEntry):
-  srsdb #0x13!@ Store return state on SVC stack
-  stmfd SP!,{LR}  @ Store the link register for the 
current mode
-  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - CPSR
-  stmfd SP!,{R0-R12}  @ Store the register state
-
-  mov   R0,#0
-  ldr   R1,ASM_PFX(CommonExceptionEntry)
-  bxR1
-
-ASM_PFX(UndefinedInstructionEntry):
-  srsdb #0x13!@ Store return state on SVC stack
-  cps   #0x13 @ Switch to SVC for common stack
-  stmfd SP!,{LR}  @ Store the link register for the 
current mode
-  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - CPSR
-  stmfd SP!,{R0-R12}  @ Store the register state
-
-  mov   r0,#1
-  ldr   r1,ASM_PFX(CommonExceptionEntry)
-  bxr1
-
-ASM_PFX(SoftwareInterruptEntry):
-  srsdb #0x13!@ Store return state on SVC stack
-  stmfd SP!,{LR}  @ Store the link register for the 
current mode
-  sub   SP,SP,#0x20   @ Save space for SP, LR, PC, IFAR - CPSR
-  stmfd SP!,{R0-R12}  @ Store the register state
-
-  mov   r0,#2
-  ldr   r1,ASM_PFX(CommonExceptionEntry)
-  bxr1
-
-ASM_PFX(PrefetchAbortEntry):
-  sub   LR,LR,#4
-  srsdb #0x13!@ Store return state on SVC stack
-  cps   #0x13 @ Switch to SVC for common stack
-  stmfd SP!,{LR}  @ Store the link register for the 
current 

Re: [edk2] [PATCH 2/5] ArmPkg/CompilerIntrinsicsLib: add GCC version of __aeabi_memset()

[Ard Biesheuvel]

On 14 December 2015 at 18:11, Leif Lindholm  wrote:
> On Mon, Dec 14, 2015 at 05:25:03PM +0100, Ard Biesheuvel wrote:
>> CLANG for ARM may emit calls to __aeabi_memset(), which is subtly different
>> from the default memset() [arguments 2 and 3 are reversed]
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S 
>> b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
>> index 0c7789eb5816..996cebdac554 100644
>> --- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
>> +++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
>> @@ -17,6 +17,7 @@
>>.text
>
>  .syntax unified ?
>

Not really necessary, since the syntax we use is interpreted in the
same way in either mode, but I will add it for completeness anyway

>>.align 2
>>GCC_ASM_EXPORT (memset)
>> +  GCC_ASM_EXPORT (__aeabi_memset)
>>
>>  # VOID
>>  # EFIAPI
>> @@ -26,13 +27,19 @@
>>  #  IN  UINT32  Size
>>  #  );
>>  ASM_PFX(memset):
>> -  cmp  r2, #0
>> +  subs ip, r2, #0
>>bxeq lr
>>@ args = 0, pretend = 0, frame = 0
>>@ frame_needed = 1, uses_anonymous_args = 0
>>  L10:
>>strb  r1, [r0], #1
>> -  subs  r2, r2, #1
>> +  subs  ip, ip, #1
>>@ While size is not 0
>>bne  L10
>>bx   lr
>> +
>> +ASM_PFX(__aeabi_memset):
>> +  subs  ip, r1, #0
>> +  bxeq  lr
>> +  mov   r1, r2
>> +  b L10
>
> So, and this is just preference, but could either the L10 loop be
> broken out into a shared subroutine with a proper name or the
> __aeabi_memset entry point be prepended to the memset entry point?
>
> Either way, a comment block stating
> # VOID
> # EFIAPI
> # __aeabi_memset (
> #  IN  VOID*Destination,
> #  IN  UINT32  Size
> #  IN  UINT32  Character,
> #  );
> wouldn't go amiss.
>

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

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[M.V.R. Ravikanth]

Yes.I am using -fno-rtti.So you want me to remove this flag?
Regards,Ravi
> Date: Tue, 15 Dec 2015 10:41:15 +0100
> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> From: ard.biesheu...@linaro.org
> To: mvrravika...@live.com
> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> 
> On 15 December 2015 at 10:07, M.V.R. Ravikanth  wrote:
> > Ok.I understand!
> >
> > I did implement new and delete API's for EFi and they are working fine
> > now.Now I am getting below linker errors which I am not sure how to resolve
> > them.Do we have any specific compiler flags for disabling these errors or I
> > have to define them in my code?
> >
> > Linker errors:
> >  1.undefined reference to `__cxa_atexit'
> 
> This is used to register destructors of global objects. If you don't
> have any such objects, you can simply define it as a function that
> does nothing. Note that if you do have such objects, you need to
> ensure that their constructors are called, i.e., you will need to
> define a EDK2 style constructor in your C++ runtime library that calls
> all the global object constructors in turn.
> 
> >  2.undefined reference to `__cxa_pure_virtual'
> >
> 
> You can simply implement this as ASSERT(FALSE) since it is something
> that should never happen.
> 
> Are you using -fno-rtti?
> 
> -- 
> Ard.
> 
> >
> >> Date: Tue, 15 Dec 2015 08:36:34 +0100
> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >> From: ard.biesheu...@linaro.org
> >> To: mvrravika...@live.com
> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >
> >>
> >> On 15 December 2015 at 04:16, M.V.R. Ravikanth 
> >> wrote:
> >> > Thanks for the information Andrew!
> >> >
> >> > So,I have to re write the entire standard library code which is in line
> >> > with
> >> > EFI environment such as AllocatePool?If yes,then it would a big task at
> >> > hand.If no,will the recompilation of standard libraries in EFI
> >> > environment
> >> > suffice here?
> >> >
> >>
> >> No. The C++ runtime is tightly coupled to the C library, which in turn
> >> is tightly coupled to the OS.
> >>
> >> It does depend on what C++ features you need: exception support will
> >> be problematic, I guess, but simply implementing new and delete should
> >> not be that difficult.
> >>
> >> > Also,when I compiled my CPP code with Visual studio/WinDDK compiler in
> >> > UDK
> >> > environment,I did not re write the standard library inline with EFI
> >> > environment.But the efi image was built and executed without any
> >> > errors.Now
> >> > I am not sure how.
> >> >
> >> > Thanks again for all your support !
> >> > 
> >> > From: Andrew Fish
> >> > Sent: ‎15-‎12-‎2015 04:28
> >> > To: M.V.R. Ravikanth
> >> > Cc: Ard Biesheuvel; edk2-devel@lists.01.org; Gao, Liming
> >> >
> >> > Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >> >
> >> >
> >> >> On Dec 14, 2015, at 10:44 AM, M.V.R. Ravikanth 
> >> >> wrote:
> >> >>
> >> >> Oh Ok great!Thanks :)
> >> >> Now I actually removed the --emit-relocs linker option and GenFw did
> >> >> not
> >> >> give me any issues.Does this mean that my final EFI binary has issues
> >> >> but
> >> >> GenFw did not report them
> >> >
> >> > The PE/COFF images that created for EFI need to be relocatable. If they
> >> > are
> >> > not relocatable they can only be loaded at thier linked address which is
> >> > usually zero (or some place close to that). The ELF relocations get
> >> > converted to PE/COFF relocations. When your application gets loaded
> >> > memory
> >> > is allocated and your application is relocated to run at that new
> >> > address.
> >> > So it is likely that you broke something by turning off --emit-relocs.
> >> >
> >> >> (this case is with standard libraries linked and my CPP program has
> >> >> reference to standard libraries)?
> >> >>
> >> >
> >> > I still think you are confused about Ard's comment about using the C++
> >> > runtime/standard libs. When your C++ code invokes new and delete what
> >> > makes
> >> > you think the Linux C++ runtime knows how to call gBS->AllocatePool()?
> >> > The
> >> > Linux C++ standard lib is going to make Linux system calls which will
> >> > most
> >> > like crash in EFI. Likewise your Linux C++ runtime is not going to run
> >> > properly on Windows.
> >> >
> >> > Thanks,
> >> >
> >> > Andrew Fish
> >> >
> >> >> -Ravi
> >> >>> Date: Mon, 14 Dec 2015 19:37:50 +0100
> >> >>> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
> >> >>> errors
> >> >>> From: ard.biesheu...@linaro.org
> >> >>> To: mvrravika...@live.com
> >> >>> CC: af...@apple.com; liming@intel.com; edk2-devel@lists.01.org
> >> >>>
> >> >>> On 14 December 2015 at 19:24, M.V.R. Ravikanth 
> >> >>> wrote:
> >>  Below are the detailed steps which I perform:
> >> 
> >>  1.Compile CPP 

Re: [edk2] [PATCH v2] ArmPkg/ArmV7Mmu: prefer non shareable memory on non-coherent hardware

[Ard Biesheuvel]

On 8 December 2015 at 16:11, Ard Biesheuvel  wrote:
> Commit SVN r18778 made all mappings of normal memory (inner) shareable,
> even on hardware that implements shareability as uncached accesses.
> The original concerns that prompted the change, regarding coherent DMA
> and virt guests migrating between CPUs, do not apply to such hardware,
> so revert to the original behavior in that case.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
> v2: use symbolic constants for the various shift and mask values
> default to shareable on unexpected values, but ASSERT() as well
>

Any more comment on this version? Thanks

>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h | 14 +++
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 42 ++--
>  2 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h 
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
> index e138613ca548..cbd3d6f654a6 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
> @@ -15,6 +15,20 @@
>  #ifndef __ARM_V7_LIB_H__
>  #define __ARM_V7_LIB_H__
>
> +#define ID_MMFR0_SHARELVL_SHIFT   12
> +#define ID_MMFR0_SHARELVL_MASK   0xf
> +#define ID_MMFR0_SHARELVL_ONE  0
> +#define ID_MMFR0_SHARELVL_TWO  1
> +
> +#define ID_MMFR0_INNERSHR_SHIFT   28
> +#define ID_MMFR0_INNERSHR_MASK   0xf
> +#define ID_MMFR0_OUTERSHR_SHIFT8
> +#define ID_MMFR0_OUTERSHR_MASK   0xf
> +
> +#define ID_MMFR0_SHR_IMP_UNCACHED  0
> +#define ID_MMFR0_SHR_IMP_HW_COHERENT   1
> +#define ID_MMFR0_SHR_IGNORED 0xf
> +
>  typedef VOID (*ARM_V7_CACHE_OPERATION)(UINT32);
>
>  VOID
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c 
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> index 23d2e43beba0..fc8ea42843b3 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> @@ -42,6 +42,42 @@ ConvertSectionAttributesToPageAttributes (
>  }
>
>  STATIC
> +BOOLEAN
> +PreferNonshareableMemory (
> +  VOID
> +  )
> +{
> +  UINTN   Mmfr;
> +  UINTN   Val;
> +
> +  if (FeaturePcdGet (PcdNormalMemoryNonshareableOverride)) {
> +return TRUE;
> +  }
> +
> +  //
> +  // Check whether the innermost level of shareability (the level we will use
> +  // by default to map normal memory) is implemented with hardware coherency
> +  // support. Otherwise, revert to mapping as non-shareable.
> +  //
> +  Mmfr = ArmReadIdMmfr0 ();
> +  switch ((Mmfr >> ID_MMFR0_SHARELVL_SHIFT) & ID_MMFR0_SHARELVL_MASK) {
> +  case ID_MMFR0_SHARELVL_ONE:
> +// one level of shareability
> +Val = (Mmfr >> ID_MMFR0_OUTERSHR_SHIFT) & ID_MMFR0_OUTERSHR_MASK;
> +break;
> +  case ID_MMFR0_SHARELVL_TWO:
> +// two levels of shareability
> +Val = (Mmfr >> ID_MMFR0_INNERSHR_SHIFT) & ID_MMFR0_INNERSHR_MASK;
> +break;
> +  default:
> +// unexpected value -> shareable is the safe option
> +ASSERT (FALSE);
> +return FALSE;
> +  }
> +  return Val != ID_MMFR0_SHR_IMP_HW_COHERENT;
> +}
> +
> +STATIC
>  VOID
>  PopulateLevel2PageTable (
>IN UINT32 *SectionEntry,
> @@ -80,7 +116,7 @@ PopulateLevel2PageTable (
>break;
>}
>
> -  if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
> +  if (PreferNonshareableMemory ()) {
>  PageAttributes &= ~TT_DESCRIPTOR_PAGE_S_SHARED;
>}
>
> @@ -189,7 +225,7 @@ FillTranslationTable (
>break;
>}
>
> -  if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
> +  if (PreferNonshareableMemory ()) {
>  Attributes &= ~TT_DESCRIPTOR_SECTION_S_SHARED;
>}
>
> @@ -281,7 +317,7 @@ ArmConfigureMmu (
>}
>
>if (TTBRAttributes & TTBR_SHAREABLE) {
> -if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
> +if (PreferNonshareableMemory ()) {
>TTBRAttributes ^= TTBR_SHAREABLE;
>  } else {
>//
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] ArmPkg/ArmGic: fix bug in GICv3 distributor configuration

[Leif Lindholm]

On Thu, Dec 03, 2015 at 02:58:36PM +0100, Ard Biesheuvel wrote:
> In the function ArmGicEnableDistributor (), the Affinity Routing Enable
> (ARE) bit, which essentially defines whether the GIC runs in v2 or v3
> mode, is inadvertently cleared when enabling the GIC distributor if it
> is running in v3 mode. So fix that.
> 
> Reported-by: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c 
> b/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
> index 31572438d9a1..f90391b716b5 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c
> @@ -33,9 +33,9 @@ ArmGicEnableDistributor (
>  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
>} else {
>  if (MmioRead32 (GicDistributorBase + ARM_GIC_ICDDCR) & 
> ARM_GIC_ICDDCR_ARE) {
> -  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x2);
> +  MmioOr32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x2);

Hilariously, the name of this register in the GIC architecture
reference manual isn't GIC_ICDDCR, but GICD_CTLR.

>  } else {
> -  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
> +  MmioOr32 (GicDistributorBase + ARM_GIC_ICDDCR, 0x1);
>  }
>}
>  }
> -- 
> 1.9.1

So, this is a bugfix, and you shouldn't have to fix the world for it,
but I dislike the magic hex values. Maybe time to make a note to go
back and clean this stuff up later on.

Reviewed-by: Leif Lindholm 

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

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[M.V.R. Ravikanth]

For  ELF EM_AARCH64 relocation 0x105,I am unable to find any .elf file from 
which I could read the re locations.All I have is a .map and a .dll.Is there 
any way to way make changes to Elf64Convert.c to support this relocation or 
else can I port the EDK2 trunk fix to current UDK?
For R_AARCH64_NONE,Can I modify the Elf64Convert.c to break when we this case?
Why I am receiving bad symbol definition error?Anything which I can fix it from 
my code point of view?
Sorry for taking out your precious time.
Thanks !
-Ravi
> Date: Tue, 15 Dec 2015 12:12:27 +0100
> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> From: ard.biesheu...@linaro.org
> To: mvrravika...@live.com
> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> 
> On 15 December 2015 at 12:04, M.V.R. Ravikanth  wrote:
> > Ard,
> > I have now compiled and linked my CPP code without standard C++
> > libraries.But still I am receiving below relocation errors.
> >
> > GenFw: ERROR 3000: Invalid
> >   WriteSections64():
> > /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> > unsupported ELF EM_AARCH64 relocation 0x105
> >
> 
> This is relocation R_AARCH64_PREL32 (261), which is a relative
> reference, not an absolute reference. The current EDK2 trunk could
> support those, but UDK does not. And actually, since the range of such
> a relocation is only 4 GB, this looks like it may be an issue with the
> compiler.
> 
> Are you able to figure out (using readelf) where exactly these
> relocations are being emitted?
> 
> > GenFw: ERROR 3000: Invalid
> >   WriteSections64():
> > /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> > unsupported ELF EM_AARCH64 relocation 0x0.
> >
> 
> This is R_AARCH64_NONE, which we should be able to ignore. Again, this
> is something we can easily fix upstream, but not in UDK14
> 
> > GenFw: ERROR 3000: Invalid
> >   WriteRelocations64():
> > /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> > unsupported ELF EM_AARCH64 relocation 0x105.
> >
> > GenFw: ERROR 3000: Invalid
> >   WriteRelocations64():
> > /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> > unsupported ELF EM_AARCH64 relocation 0x0.
> >
> > GenFw: ERROR 3000: Invalid
> >
> > /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> > bad symbol definition.
> >
> > I have also set the -mcmodel to large.Now,the next thing I have done is
> > compiled a simple C++ helloworld program without any reference to c++
> > libraries and I am still receiving the same above errors from GenFw.
> >
> > -Ravi
> > 
> > From: mvrravika...@live.com
> > To: ard.biesheu...@linaro.org
> > CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> > Subject: RE: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> > Date: Tue, 15 Dec 2015 15:42:06 +0530
> >
> >
> > Oh ok.I have implemented the __cxa_pure_virtual() and its being
> > executed.Will let you know the results :)
> >
> > Thanks a ton again! It really means a lot to me.
> >
> > Regards,
> > Ravi
> >> Date: Tue, 15 Dec 2015 11:08:22 +0100
> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >> From: ard.biesheu...@linaro.org
> >> To: mvrravika...@live.com
> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >>
> >> On 15 December 2015 at 11:06, M.V.R. Ravikanth 
> >> wrote:
> >> > Yes.I am using -fno-rtti.So you want me to remove this flag?
> >> >
> >>
> >> No, you should keep it. As I said, things like exceptions and RTTI
> >> will make your job a lot more difficult. I was just curious whether
> >> you could get rid of the call to __cxa_pure_virtual() by disabling
> >> RTTI, but you have already done so.
> >>
> >> --
> >> Ard.
> >>
> >> >> Date: Tue, 15 Dec 2015 10:41:15 +0100
> >> >
> >> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
> >> >> errors
> >> >> From: ard.biesheu...@linaro.org
> >> >> To: mvrravika...@live.com
> >> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >> >>
> >> >> On 15 December 2015 at 10:07, M.V.R. Ravikanth 
> >> >> wrote:
> >> >> > Ok.I understand!
> >> >> >
> >> >> > I did implement new and delete API's for EFi and they are working
> >> >> > fine
> >> >> > now.Now I am getting below linker errors which I am not sure how to
> >> >> > resolve
> >> >> > them.Do we have any specific compiler flags for disabling these
> >> >> > errors
> >> >> > or I
> >> >> > have to define 

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[Ard Biesheuvel]

On 15 December 2015 at 12:04, M.V.R. Ravikanth  wrote:
> Ard,
> I have now compiled and linked my CPP code without standard C++
> libraries.But still I am receiving below relocation errors.
>
> GenFw: ERROR 3000: Invalid
>   WriteSections64():
> /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> unsupported ELF EM_AARCH64 relocation 0x105
>

This is relocation R_AARCH64_PREL32 (261), which is a relative
reference, not an absolute reference. The current EDK2 trunk could
support those, but UDK does not. And actually, since the range of such
a relocation is only 4 GB, this looks like it may be an issue with the
compiler.

Are you able to figure out (using readelf) where exactly these
relocations are being emitted?

> GenFw: ERROR 3000: Invalid
>   WriteSections64():
> /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> unsupported ELF EM_AARCH64 relocation 0x0.
>

This is R_AARCH64_NONE, which we should be able to ignore. Again, this
is something we can easily fix upstream, but not in UDK14

> GenFw: ERROR 3000: Invalid
>   WriteRelocations64():
> /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> unsupported ELF EM_AARCH64 relocation 0x105.
>
> GenFw: ERROR 3000: Invalid
>   WriteRelocations64():
> /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> unsupported ELF EM_AARCH64 relocation 0x0.
>
> GenFw: ERROR 3000: Invalid
>
> /home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
> bad symbol definition.
>
> I have also set the -mcmodel to large.Now,the next thing I have done is
> compiled a simple C++ helloworld program without any reference to c++
> libraries and I am still receiving the same above errors from GenFw.
>
> -Ravi
> 
> From: mvrravika...@live.com
> To: ard.biesheu...@linaro.org
> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> Subject: RE: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> Date: Tue, 15 Dec 2015 15:42:06 +0530
>
>
> Oh ok.I have implemented the __cxa_pure_virtual() and its being
> executed.Will let you know the results :)
>
> Thanks a ton again! It really means a lot to me.
>
> Regards,
> Ravi
>> Date: Tue, 15 Dec 2015 11:08:22 +0100
>> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
>> From: ard.biesheu...@linaro.org
>> To: mvrravika...@live.com
>> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
>>
>> On 15 December 2015 at 11:06, M.V.R. Ravikanth 
>> wrote:
>> > Yes.I am using -fno-rtti.So you want me to remove this flag?
>> >
>>
>> No, you should keep it. As I said, things like exceptions and RTTI
>> will make your job a lot more difficult. I was just curious whether
>> you could get rid of the call to __cxa_pure_virtual() by disabling
>> RTTI, but you have already done so.
>>
>> --
>> Ard.
>>
>> >> Date: Tue, 15 Dec 2015 10:41:15 +0100
>> >
>> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
>> >> errors
>> >> From: ard.biesheu...@linaro.org
>> >> To: mvrravika...@live.com
>> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
>> >>
>> >> On 15 December 2015 at 10:07, M.V.R. Ravikanth 
>> >> wrote:
>> >> > Ok.I understand!
>> >> >
>> >> > I did implement new and delete API's for EFi and they are working
>> >> > fine
>> >> > now.Now I am getting below linker errors which I am not sure how to
>> >> > resolve
>> >> > them.Do we have any specific compiler flags for disabling these
>> >> > errors
>> >> > or I
>> >> > have to define them in my code?
>> >> >
>> >> > Linker errors:
>> >> > 1.undefined reference to `__cxa_atexit'
>> >>
>> >> This is used to register destructors of global objects. If you don't
>> >> have any such objects, you can simply define it as a function that
>> >> does nothing. Note that if you do have such objects, you need to
>> >> ensure that their constructors are called, i.e., you will need to
>> >> define a EDK2 style constructor in your C++ runtime library that calls
>> >> all the global object constructors in turn.
>> >>
>> >> > 2.undefined reference to `__cxa_pure_virtual'
>> >> >
>> >>
>> >> You can simply implement this as ASSERT(FALSE) since it is something
>> >> that should never happen.
>> >>
>> >> Are you using -fno-rtti?
>> >>
>> >> --
>> >> Ard.
>> >>
>> >> >
>> >> >> Date: Tue, 15 Dec 2015 08:36:34 +0100
>> >> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
>> >> >> errors
>> >> >> From: ard.biesheu...@linaro.org
>> >> >> To: 

Re: [edk2] [PATCH v2] ArmPkg/ArmV7Mmu: prefer non shareable memory on non-coherent hardware

[Leif Lindholm]

On Tue, Dec 15, 2015 at 11:10:49AM +0100, Ard Biesheuvel wrote:
> On 8 December 2015 at 16:11, Ard Biesheuvel  wrote:
> > Commit SVN r18778 made all mappings of normal memory (inner) shareable,
> > even on hardware that implements shareability as uncached accesses.
> > The original concerns that prompted the change, regarding coherent DMA
> > and virt guests migrating between CPUs, do not apply to such hardware,
> > so revert to the original behavior in that case.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > v2: use symbolic constants for the various shift and mask values
> > default to shareable on unexpected values, but ASSERT() as well
> >
> 
> Any more comment on this version? Thanks

If Eugene is happy - for my part:
Reviewed-by: Leif Lindholm 

> >  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h | 14 +++
> >  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 42 ++--
> >  2 files changed, 53 insertions(+), 3 deletions(-)
> >
> > diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h 
> > b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
> > index e138613ca548..cbd3d6f654a6 100644
> > --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
> > +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h
> > @@ -15,6 +15,20 @@
> >  #ifndef __ARM_V7_LIB_H__
> >  #define __ARM_V7_LIB_H__
> >
> > +#define ID_MMFR0_SHARELVL_SHIFT   12
> > +#define ID_MMFR0_SHARELVL_MASK   0xf
> > +#define ID_MMFR0_SHARELVL_ONE  0
> > +#define ID_MMFR0_SHARELVL_TWO  1
> > +
> > +#define ID_MMFR0_INNERSHR_SHIFT   28
> > +#define ID_MMFR0_INNERSHR_MASK   0xf
> > +#define ID_MMFR0_OUTERSHR_SHIFT8
> > +#define ID_MMFR0_OUTERSHR_MASK   0xf
> > +
> > +#define ID_MMFR0_SHR_IMP_UNCACHED  0
> > +#define ID_MMFR0_SHR_IMP_HW_COHERENT   1
> > +#define ID_MMFR0_SHR_IGNORED 0xf
> > +
> >  typedef VOID (*ARM_V7_CACHE_OPERATION)(UINT32);
> >
> >  VOID
> > diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c 
> > b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> > index 23d2e43beba0..fc8ea42843b3 100644
> > --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> > +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> > @@ -42,6 +42,42 @@ ConvertSectionAttributesToPageAttributes (
> >  }
> >
> >  STATIC
> > +BOOLEAN
> > +PreferNonshareableMemory (
> > +  VOID
> > +  )
> > +{
> > +  UINTN   Mmfr;
> > +  UINTN   Val;
> > +
> > +  if (FeaturePcdGet (PcdNormalMemoryNonshareableOverride)) {
> > +return TRUE;
> > +  }
> > +
> > +  //
> > +  // Check whether the innermost level of shareability (the level we will 
> > use
> > +  // by default to map normal memory) is implemented with hardware 
> > coherency
> > +  // support. Otherwise, revert to mapping as non-shareable.
> > +  //
> > +  Mmfr = ArmReadIdMmfr0 ();
> > +  switch ((Mmfr >> ID_MMFR0_SHARELVL_SHIFT) & ID_MMFR0_SHARELVL_MASK) {
> > +  case ID_MMFR0_SHARELVL_ONE:
> > +// one level of shareability
> > +Val = (Mmfr >> ID_MMFR0_OUTERSHR_SHIFT) & ID_MMFR0_OUTERSHR_MASK;
> > +break;
> > +  case ID_MMFR0_SHARELVL_TWO:
> > +// two levels of shareability
> > +Val = (Mmfr >> ID_MMFR0_INNERSHR_SHIFT) & ID_MMFR0_INNERSHR_MASK;
> > +break;
> > +  default:
> > +// unexpected value -> shareable is the safe option
> > +ASSERT (FALSE);
> > +return FALSE;
> > +  }
> > +  return Val != ID_MMFR0_SHR_IMP_HW_COHERENT;
> > +}
> > +
> > +STATIC
> >  VOID
> >  PopulateLevel2PageTable (
> >IN UINT32 *SectionEntry,
> > @@ -80,7 +116,7 @@ PopulateLevel2PageTable (
> >break;
> >}
> >
> > -  if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
> > +  if (PreferNonshareableMemory ()) {
> >  PageAttributes &= ~TT_DESCRIPTOR_PAGE_S_SHARED;
> >}
> >
> > @@ -189,7 +225,7 @@ FillTranslationTable (
> >break;
> >}
> >
> > -  if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
> > +  if (PreferNonshareableMemory ()) {
> >  Attributes &= ~TT_DESCRIPTOR_SECTION_S_SHARED;
> >}
> >
> > @@ -281,7 +317,7 @@ ArmConfigureMmu (
> >}
> >
> >if (TTBRAttributes & TTBR_SHAREABLE) {
> > -if (FeaturePcdGet(PcdNormalMemoryNonshareableOverride)) {
> > +if (PreferNonshareableMemory ()) {
> >TTBRAttributes ^= TTBR_SHAREABLE;
> >  } else {
> >//
> > --
> > 1.9.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[M.V.R. Ravikanth]

Oh ok.I have implemented the __cxa_pure_virtual() and its being executed.Will 
let you know the results :)
Thanks a ton again! It really means a lot to me.

Regards,Ravi> Date: Tue, 15 Dec 2015 11:08:22 +0100
> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> From: ard.biesheu...@linaro.org
> To: mvrravika...@live.com
> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> 
> On 15 December 2015 at 11:06, M.V.R. Ravikanth  wrote:
> > Yes.I am using -fno-rtti.So you want me to remove this flag?
> >
> 
> No, you should keep it. As I said, things like exceptions and RTTI
> will make your job a lot more difficult. I was just curious whether
> you could get rid of the call to __cxa_pure_virtual() by disabling
> RTTI, but you have already done so.
> 
> -- 
> Ard.
> 
> >> Date: Tue, 15 Dec 2015 10:41:15 +0100
> >
> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >> From: ard.biesheu...@linaro.org
> >> To: mvrravika...@live.com
> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >>
> >> On 15 December 2015 at 10:07, M.V.R. Ravikanth 
> >> wrote:
> >> > Ok.I understand!
> >> >
> >> > I did implement new and delete API's for EFi and they are working fine
> >> > now.Now I am getting below linker errors which I am not sure how to
> >> > resolve
> >> > them.Do we have any specific compiler flags for disabling these errors
> >> > or I
> >> > have to define them in my code?
> >> >
> >> > Linker errors:
> >> > 1.undefined reference to `__cxa_atexit'
> >>
> >> This is used to register destructors of global objects. If you don't
> >> have any such objects, you can simply define it as a function that
> >> does nothing. Note that if you do have such objects, you need to
> >> ensure that their constructors are called, i.e., you will need to
> >> define a EDK2 style constructor in your C++ runtime library that calls
> >> all the global object constructors in turn.
> >>
> >> > 2.undefined reference to `__cxa_pure_virtual'
> >> >
> >>
> >> You can simply implement this as ASSERT(FALSE) since it is something
> >> that should never happen.
> >>
> >> Are you using -fno-rtti?
> >>
> >> --
> >> Ard.
> >>
> >> >
> >> >> Date: Tue, 15 Dec 2015 08:36:34 +0100
> >> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
> >> >> errors
> >> >> From: ard.biesheu...@linaro.org
> >> >> To: mvrravika...@live.com
> >> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >> >
> >> >>
> >> >> On 15 December 2015 at 04:16, M.V.R. Ravikanth 
> >> >> wrote:
> >> >> > Thanks for the information Andrew!
> >> >> >
> >> >> > So,I have to re write the entire standard library code which is in
> >> >> > line
> >> >> > with
> >> >> > EFI environment such as AllocatePool?If yes,then it would a big task
> >> >> > at
> >> >> > hand.If no,will the recompilation of standard libraries in EFI
> >> >> > environment
> >> >> > suffice here?
> >> >> >
> >> >>
> >> >> No. The C++ runtime is tightly coupled to the C library, which in turn
> >> >> is tightly coupled to the OS.
> >> >>
> >> >> It does depend on what C++ features you need: exception support will
> >> >> be problematic, I guess, but simply implementing new and delete should
> >> >> not be that difficult.
> >> >>
> >> >> > Also,when I compiled my CPP code with Visual studio/WinDDK compiler
> >> >> > in
> >> >> > UDK
> >> >> > environment,I did not re write the standard library inline with EFI
> >> >> > environment.But the efi image was built and executed without any
> >> >> > errors.Now
> >> >> > I am not sure how.
> >> >> >
> >> >> > Thanks again for all your support !
> >> >> > 
> >> >> > From: Andrew Fish
> >> >> > Sent: ‎15-‎12-‎2015 04:28
> >> >> > To: M.V.R. Ravikanth
> >> >> > Cc: Ard Biesheuvel; edk2-devel@lists.01.org; Gao, Liming
> >> >> >
> >> >> > Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
> >> >> > errors
> >> >> >
> >> >> >
> >> >> >> On Dec 14, 2015, at 10:44 AM, M.V.R. Ravikanth
> >> >> >> 
> >> >> >> wrote:
> >> >> >>
> >> >> >> Oh Ok great!Thanks :)
> >> >> >> Now I actually removed the --emit-relocs linker option and GenFw did
> >> >> >> not
> >> >> >> give me any issues.Does this mean that my final EFI binary has
> >> >> >> issues
> >> >> >> but
> >> >> >> GenFw did not report them
> >> >> >
> >> >> > The PE/COFF images that created for EFI need to be relocatable. If
> >> >> > they
> >> >> > are
> >> >> > not relocatable they can only be loaded at thier linked address which
> >> >> > is
> >> >> > usually zero (or some place close to that). The ELF relocations get
> >> >> > converted to PE/COFF relocations. When your application gets loaded
> >> >> > memory
> >> >> > is allocated and your application is relocated to run at that new
> >> >> > address.
> >> >> > So it is likely that you broke something by turning off
> >> 

Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors

[M.V.R. Ravikanth]

Ard,I have now compiled and linked my CPP code without standard C++ 
libraries.But still I am receiving below relocation errors.
GenFw: ERROR 3000: Invalid  WriteSections64(): 
/home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
 unsupported ELF EM_AARCH64 relocation 0x105
GenFw: ERROR 3000: Invalid  WriteSections64(): 
/home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
 unsupported ELF EM_AARCH64 relocation 0x0.
GenFw: ERROR 3000: Invalid  WriteRelocations64(): 
/home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
 unsupported ELF EM_AARCH64 relocation 0x105.
GenFw: ERROR 3000: Invalid  WriteRelocations64(): 
/home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
 unsupported ELF EM_AARCH64 relocation 0x0.
GenFw: ERROR 3000: Invalid  
/home/udk14/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/ShellPkg/Application/CLI/UNIV_VIVA_Cli/Build/Efi/StoreCli/CliUEFI/DEBUG/storcli.dll
 bad symbol definition.
I have also set the -mcmodel to large.Now,the next thing I have done is 
compiled a simple C++ helloworld program without any reference to c++ libraries 
and I am still receiving the same above errors from GenFw.
-RaviFrom: mvrravika...@live.com
To: ard.biesheu...@linaro.org
CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
Subject: RE: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
Date: Tue, 15 Dec 2015 15:42:06 +0530




Oh ok.I have implemented the __cxa_pure_virtual() and its being executed.Will 
let you know the results :)
Thanks a ton again! It really means a lot to me.

Regards,Ravi> Date: Tue, 15 Dec 2015 11:08:22 +0100
> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> From: ard.biesheu...@linaro.org
> To: mvrravika...@live.com
> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> 
> On 15 December 2015 at 11:06, M.V.R. Ravikanth  wrote:
> > Yes.I am using -fno-rtti.So you want me to remove this flag?
> >
> 
> No, you should keep it. As I said, things like exceptions and RTTI
> will make your job a lot more difficult. I was just curious whether
> you could get rid of the call to __cxa_pure_virtual() by disabling
> RTTI, but you have already done so.
> 
> -- 
> Ard.
> 
> >> Date: Tue, 15 Dec 2015 10:41:15 +0100
> >
> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64() errors
> >> From: ard.biesheu...@linaro.org
> >> To: mvrravika...@live.com
> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >>
> >> On 15 December 2015 at 10:07, M.V.R. Ravikanth 
> >> wrote:
> >> > Ok.I understand!
> >> >
> >> > I did implement new and delete API's for EFi and they are working fine
> >> > now.Now I am getting below linker errors which I am not sure how to
> >> > resolve
> >> > them.Do we have any specific compiler flags for disabling these errors
> >> > or I
> >> > have to define them in my code?
> >> >
> >> > Linker errors:
> >> > 1.undefined reference to `__cxa_atexit'
> >>
> >> This is used to register destructors of global objects. If you don't
> >> have any such objects, you can simply define it as a function that
> >> does nothing. Note that if you do have such objects, you need to
> >> ensure that their constructors are called, i.e., you will need to
> >> define a EDK2 style constructor in your C++ runtime library that calls
> >> all the global object constructors in turn.
> >>
> >> > 2.undefined reference to `__cxa_pure_virtual'
> >> >
> >>
> >> You can simply implement this as ASSERT(FALSE) since it is something
> >> that should never happen.
> >>
> >> Are you using -fno-rtti?
> >>
> >> --
> >> Ard.
> >>
> >> >
> >> >> Date: Tue, 15 Dec 2015 08:36:34 +0100
> >> >> Subject: Re: [edk2] GenFW Error 3000 Invalid WriteRelocations64()
> >> >> errors
> >> >> From: ard.biesheu...@linaro.org
> >> >> To: mvrravika...@live.com
> >> >> CC: af...@apple.com; edk2-devel@lists.01.org; liming@intel.com
> >> >
> >> >>
> >> >> On 15 December 2015 at 04:16, M.V.R. Ravikanth 
> >> >> wrote:
> >> >> > Thanks for the information Andrew!
> >> >> >
> >> >> > So,I have to re write the entire standard library code which is in
> >> >> > line
> >> >> > with
> >> >> > EFI environment such as AllocatePool?If yes,then it would a big task
> >> >> > at
> >> >> > hand.If no,will the recompilation of standard libraries in EFI
> >> >> > environment
> >> >> > suffice here?
> >> >> >
> >> >>
> >> >> No. The C++ runtime is tightly coupled to the C library, which in turn
> >> >> is tightly coupled to the OS.
> >> >>
> >> >> It does depend on what C++ features you need: exception support will
> 

Re: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg packages

[Kinney, Michael D]

QuarkSocPkg committed as SVN r19286 
QuarkPlatformPkg committed as SVN r19287

> -Original Message-
> From: Justen, Jordan L
> Sent: Tuesday, December 15, 2015 11:30 AM
> To: Kinney, Michael D ; edk2-
> de...@lists.01.org (edk2-devel@lists.01.org)  de...@lists.01.org>
> Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and QuarkPlatformPkg
> packages
> 
> On 2015-12-15 09:54:25, Kinney, Michael D wrote:
> > Jordan,
> >
> > Reponses included below.
> >
> > 1) edk2: Maintainers.txt patch email sent.
> > 2) Thank you very much for ack and detailed review/feedback in
> Quark*Pkgs
> > 3) I have fixed all the items for the edk2-non-osi repository
> and pushed them to:
> >
> > https://github.com/mdkinney/edk2-non-osi.git
> >
> > Can you create the new edk2-non-osi repository on
> tianocore and
> > import this content?
> >
> 
> I pushed your branch to:
> 
> https://github.com/tianocore/edk2-non-osi
> 
> I guess this is our first repo where the upstream is git rather
> than
> svn...
> 
> -Jordan
> 
> >
> > > -Original Message-
> > > From: Justen, Jordan L
> > > Sent: Monday, December 14, 2015 11:47 PM
> > > To: Kinney, Michael D ; edk2-
> > > de...@lists.01.org (edk2-devel@lists.01.org)  > > de...@lists.01.org>
> > > Subject: RE: [edk2] [PATCH] Add QuarkSocPkg and
> QuarkPlatformPkg
> > > packages
> > >
> > > On 2015-12-13 14:48:54, Kinney, Michael D wrote:
> > > > Jordan,
> > > >
> > > > I have updated to Quark_V3 that uses this concept along
> with a
> > > > proposed edk2-non-osi repository with a new
> QuarkSocBinPkg. It
> > > uses
> > > > PACKAGES_PATH to support the multiple repositories to do a
> > > build.
> > > > The content is posted for review on GitHub.
> > > >
> > > > The QuarkSocPkg and QuarkPlatformPkg are in branch
> Quark_V3 on
> > > GitHub at:
> > > >
> > > > https://github.com/mdkinney/edk2.git
> > > >
> > > > The edk2-non-iso repository with the QuarkSocBinPkg is on
> > > GitHub at:
> > > >
> > > > https://github.com/mdkinney/edk2-non-osi.git
> > > >
> > > > Here are the instructions I use to clone the content and
> set
> > > > environment variables to perform platform builds.
> > > >
> > > >
> > >
> 
> > > ==
> > > > git clone https://github.com/mdkinney/edk2.git --branch
> > > Quark_V3
> > >
> > > I notice that this file doesn't have the standard copyright
> > > header:
> > >
> > >
> QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLibModStrs.un
> > > i
> > >
> > > I found this with:
> > >
> > > $ git grep -L 'http://opensource.org/licenses/bsd-
> license.php'
> > > Quark*
> > >
> >
> > Thanks.  I have fixed this.
> >
> > > Also, QuarkPlatformPkg/License.txt and
> QuarkSocPkg/License.txt
> > > are
> > > using unix line endings. How about copying
> MdePkg/License.txt
> > > directly?
> > >
> > > I found this with:
> > >
> > > $ md5sum */License.txt
> > >
> >
> > I found these 2 license files yesterday with wrong line
> endings.  I have fixed them.
> > I also found a C source file with a Unicode '-' character in
> it, and I fixed that too.
> >
> > > With these fixed:
> > >
> > > Acked-by: Jordan Justen 
> > >
> > > So, I guess these probably two changes are ready to commit,
> > > right?
> >
> > Thank you very much for the detailed reviews and feedback.
> > Yes.  I am ready to commit these two packages.
> >
> > >
> > > * QuarkPlatformPkg: Add new package for Galileo boards
> > > * QuarkSocPkg: Add new package for Quark SoC X1000
> > >
> > > Can you send out a patch for the Maintainers.txt?
> >
> > Yes.  I have sent patch review email.
> >
> > >
> > > > git clone https://github.com/tianocore/edk2-FatPkg.git
> FatPkg
> > > > git clone https://github.com/mdkinney/edk2-non-osi.git
> > >
> > > I also reviewed the updated edk2-non-osi tree with
> > > 5573e513dfb88f96c8ae08471e369c335a540a37 "QuarkSocBinPkg:
> > > Reformat
> > > IntelProprietaryLicense.txt". I think you should just squash
> > > that into
> > > the previous commit.
> >
> > Done
> >
> > >
> > > Also, in:
> > >
> > > In QuarkSocBinPkg/License.txt
> > >
> > > You have this text:
> > >
> > > > Additional terms:
> > > > -
> > > >
> > >
> QuarkSocBinPkg\QuarkNorthCluster\Binary\QuarkMicrocode\IntelProp
> > > rietaryLicense.txt
> > >
> > > This sounds similar to the FAT driver, where all of the
> content
> > > has
> > > BSD + and additional term. But, in this case, the license
> only
> > > applies
> > > to 1 file. How about something like what we have in
> > > OvmfPkg/License.txt? For example:
> > >
> > > > Some files are subject to a license documented in the
> > > > IntelProprietaryLicense.txt file. These files are in the
> same
> > > > directory as IntelProprietaryLicense.txt, and they do not
> have
> > > a
> > > > license specified within the file.
> >
> > Done
> >
> > >
> > > -Jordan
> > >
> > > > git clone 

[edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get installed above 4GB

[Samer El-Haj-Mahmoud]

Some ARM systems do not have available memory below 4GB, and still
support ACPI. This patch allows the tables to get loaded above 4GB
if the allocation below 4GB fails.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../AcpiSupportAcpiSupportProtocol.c   | 69 --
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
 
b/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
index 6443c3a..72a7fe1 100644
--- 
a/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
+++ 
b/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
@@ -2,6 +2,7 @@
   ACPI Support Protocol implementation
 
 Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -533,6 +534,14 @@ ReallocateAcpiTableBuffer (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (TotalSize),
+
+);
+  }
+  if (EFI_ERROR (Status)) {
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -548,8 +557,13 @@ ReallocateAcpiTableBuffer (
   //
   // Update RSDP to point to the new Rsdt and Xsdt address.
   //
-  AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
-  AcpiSupportInstance->Rsdp3->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt3;
+  if ((UINTN) AcpiSupportInstance->Rsdt3 < BASE_4GB) {
+AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
+AcpiSupportInstance->Rsdp3->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt3;
+  } else {
+AcpiSupportInstance->Rsdp1->RsdtAddress = 0;
+AcpiSupportInstance->Rsdp3->RsdtAddress = 0;
+  }
   CurrentData = (UINT64) (UINTN) AcpiSupportInstance->Xsdt;
   CopyMem (>Rsdp3->XsdtAddress, , sizeof 
(UINT64));
 
@@ -669,6 +683,15 @@ AddTableToList (
 CurrentTableList->NumberOfPages,
 >PageAddress
 );
+
+if (EFI_ERROR (Status)) {
+  Status = gBS->AllocatePages (
+  AllocateAnyPages,
+  EfiACPIMemoryNVS,
+  CurrentTableList->NumberOfPages,
+  >PageAddress
+  );
+}
   } else {
 //
 // All other tables are ACPI reclaim memory, no alignment requirements.
@@ -679,6 +702,15 @@ AddTableToList (
 CurrentTableList->NumberOfPages,
 >PageAddress
 );
+
+if (EFI_ERROR (Status)) {
+  Status = gBS->AllocatePages (
+  AllocateAnyPages,
+  EfiACPIReclaimMemory,
+  CurrentTableList->NumberOfPages,
+  >PageAddress
+  );
+}
   }
   //
   // Check return value from memory alloc.
@@ -1785,6 +1817,15 @@ AcpiSupportAcpiSupportConstructor (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (RsdpTableSize),
+
+);
+  }
+
+  if (EFI_ERROR (Status)) {
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -1823,6 +1864,15 @@ AcpiSupportAcpiSupportConstructor (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (TotalSize),
+
+);
+  }
+
+  if (EFI_ERROR (Status)) {
 gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)AcpiSupportInstance->Rsdp1, 
EFI_SIZE_TO_PAGES (RsdpTableSize));
 return EFI_OUT_OF_RESOURCES;
   }
@@ -1843,13 +1893,24 @@ AcpiSupportAcpiSupportConstructor (
   CopyMem (>Rsdp1->Signature, , sizeof 
(UINT64));
   CopyMem (AcpiSupportInstance->Rsdp1->OemId, PcdGetPtr (PcdAcpiDefaultOemId), 
sizeof (AcpiSupportInstance->Rsdp1->OemId));
   AcpiSupportInstance->Rsdp1->Reserved= EFI_ACPI_RESERVED_BYTE;
-  AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
+  
+  if ((UINTN) AcpiSupportInstance->Rsdt1 < BASE_4GB) {
+AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
+  } else {
+AcpiSupportInstance->Rsdp3->RsdtAddress = 0;
+  }
 
   CurrentData = EFI_ACPI_3_0_ROOT_SYSTEM_DESCRIPTION_POINTER_SIGNATURE;
   CopyMem (>Rsdp3->Signature, , sizeof 
(UINT64));
   CopyMem 

Re: [edk2] [PATCH] SecurityPkg: Add TCG physical presence definition for clear deactivate

[El-Haj-Mahmoud, Samer]

Jiewen,

Agreed. This is a mistake, and you can discard this patch.

Thanks,
--Samer


-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Monday, December 14, 2015 6:58 PM
To: El-Haj-Mahmoud, Samer ; 
edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; Zhang, Chao B 

Subject: RE: [edk2] [PATCH] SecurityPkg: Add TCG physical presence definition 
for clear deactivate

HI Samer
I checked TCG official web, the latest PPI spec at 
http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification
Version 0.52, 
http://www.trustedcomputinggroup.org/files/resource_files/D6850418-1A4B-B294-D0427225D4301E82/Physical%20Presence%20Interface_1-30_0-52.pdf

I checked "Table 1: Physical Presence Interface Operation Summary for TPM 1.2", 
But I cannot to find " PHYSICAL_PRESENCE_CLEAR_DEACTIVATE_DISABLE   
 23"
23 - 127 Reserved

Would you please share the info on where you get this definition?

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Tuesday, December 15, 2015 8:33 AM
To: edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud; Zhang, Chao B
Subject: [edk2] [PATCH] SecurityPkg: Add TCG physical presence definition for 
clear deactivate

Add PHYSICAL_PRESENCE_CLEAR_DEACTIVATE_DISABLE

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 SecurityPkg/Include/Guid/PhysicalPresenceData.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/SecurityPkg/Include/Guid/PhysicalPresenceData.h 
b/SecurityPkg/Include/Guid/PhysicalPresenceData.h
index 165b464..2ecb446 100644
--- a/SecurityPkg/Include/Guid/PhysicalPresenceData.h
+++ b/SecurityPkg/Include/Guid/PhysicalPresenceData.h
@@ -5,6 +5,7 @@
   is saved to variable.
 
 Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 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 @@ -57,6 +58,8 @@ 
typedef struct {
 #define PHYSICAL_PRESENCE_SET_NO_PPI_MAINTENANCE_TRUE 20
 #define PHYSICAL_PRESENCE_ENABLE_ACTIVATE_CLEAR   21
 #define PHYSICAL_PRESENCE_ENABLE_ACTIVATE_CLEAR_ENABLE_ACTIVATE   22
+#define PHYSICAL_PRESENCE_CLEAR_DEACTIVATE_DISABLE23
+
 
 //
 // This variable is used to save TPM Management Flags and corresponding 
operations.
--
2.6.3.windows.1

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

Re: [edk2] [PATCH] MdePkg: Add GIC version to ACPI and 6 definitions

[Yao, Jiewen]

OK. I can help on that.

Thanks to fix that.

Thank you
Yao Jiewen

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Tuesday, December 15, 2015 8:54 AM
To: edk2-devel@lists.01.org; Yao, Jiewen
Subject: RE: [edk2] [PATCH] MdePkg: Add GIC version to ACPI and 6 definitions

Thanks Jiewen. I agree.

I don't have permission to commit. Can you please fix the comment and commit it 
for me?






-Original Message-
From: Yao, Jiewen [jiewen@intel.com]
Received: Monday, 14 Dec 2015, 6:51PM
To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]; 
edk2-devel@lists.01.org 
[edk2-devel@lists.01.org]
CC: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]
Subject: RE: [edk2] [PATCH] MdePkg: Add GIC version to ACPI and 6 definitions
HI Samer
The patch is good.
The check in comment seems not match the file you changed. Should it be "The 
GicVersion field is defined in ACPI 5.1 and 6.0"?

Reviewed-by: jiewen@intel.com, if you change 
the comment, when you check in.



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Tuesday, December 15, 2015 7:53 AM
To: edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud
Subject: [edk2] [PATCH] MdePkg: Add GIC version to ACPI and 6 definitions

The GicVersion field is defined in ACPI 5.0 and 6.0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud >
---
 MdePkg/Include/IndustryStandard/Acpi51.h | 12 +++-  
MdePkg/Include/IndustryStandard/Acpi60.h | 12 +++-
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h 
b/MdePkg/Include/IndustryStandard/Acpi51.h
index 9e643bc..034094e 100644
--- a/MdePkg/Include/IndustryStandard/Acpi51.h
+++ b/MdePkg/Include/IndustryStandard/Acpi51.h
@@ -3,6 +3,7 @@

   Copyright (c) 2014 Hewlett-Packard Development Company, L.P.
   Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
+  (C) Copyright 2015 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
@@ -529,10 +530,19 @@ typedef struct {
   UINT32  GicId;
   UINT64  PhysicalBaseAddress;
   UINT32  SystemVectorBase;
-  UINT32  Reserved2;
+  UINT8   GicVersion;
+  UINT8   Reserved2[3];
 } EFI_ACPI_5_1_GIC_DISTRIBUTOR_STRUCTURE;

 ///
+/// GIC Version
+///
+#define EFI_ACPI_5_1_GIC_V2   0x01
+#define EFI_ACPI_5_1_GIC_V2m  0x02
+#define EFI_ACPI_5_1_GIC_V3   0x03
+#define EFI_ACPI_5_1_GIC_V4   0x04
+
+///
 /// GIC MSI Frame Structure
 ///
 typedef struct {
diff --git a/MdePkg/Include/IndustryStandard/Acpi60.h 
b/MdePkg/Include/IndustryStandard/Acpi60.h
index 3dac316..f0e4151 100644
--- a/MdePkg/Include/IndustryStandard/Acpi60.h
+++ b/MdePkg/Include/IndustryStandard/Acpi60.h
@@ -2,6 +2,7 @@
   ACPI 6.0 definitions from the ACPI Specification Revision 6.0 April, 2015.

   Copyright (c) 2015, Intel Corporation. All rights reserved.
+ (C) Copyright 2015 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
@@ -532,10 +533,19 @@ typedef struct {
   UINT32  GicId;
   UINT64  PhysicalBaseAddress;
   UINT32  SystemVectorBase;
-  UINT32  Reserved2;
+  UINT8   GicVersion;
+  UINT8   Reserved2[3];
 } EFI_ACPI_6_0_GIC_DISTRIBUTOR_STRUCTURE;

 ///
+/// GIC Version
+///
+#define EFI_ACPI_6_0_GIC_V1   0x01
+#define EFI_ACPI_6_0_GIC_V2   0x02
+#define EFI_ACPI_6_0_GIC_V3   0x03
+#define EFI_ACPI_6_0_GIC_V4   0x04
+
+///
 /// GIC MSI Frame Structure
 ///
 typedef struct {
--
2.6.3.windows.1

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

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Baranee,

What build flags are you using?

Most platforms can add the following in their DSC file to get this to work form 
VS20xx tool chains.

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
  MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Anbazhagan, Baraneedharan
> Sent: Tuesday, December 15, 2015 8:31 AM
> To: Kinney, Michael D ; Yao, Jiewen
> ; Laszlo Ersek 
> Cc: Hamel, Lee M ; Barlow, Dallas
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Hi,
> When I tried to enable section alignment in DSC for Runtime
> modules, am getting a build error that section alignment and
> file alignment doesn't match(GenFvInternalLib.c). Am using
> VS2012x86 build tools. Whether any other build flag needs to be
> set?
> 
> - Baranee
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Kinney,
> > Michael D
> > Sent: Monday, December 07, 2015 8:23 PM
> > To: Yao, Jiewen; Laszlo Ersek; Kinney, Michael D
> > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> >
> > Jiewen,
> >
> > I agree that is a good place to put the error message.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Sunday, December 6, 2015 7:06 PM
> > > To: Kinney, Michael D ; Laszlo
> Ersek
> > > ; Kinney, Michael D
> 
> > > Cc: Hamel, Lee M ; edk2-
> de...@lists.01.org
> > > 
> > > Subject: RE: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Hi Mike
> > > I agree that we can change this from ERROR to WARNING, and
> only add 1 ERROR
> > message.
> > >
> > > However, the
> \MdeModulePkg\Universal\PropertiesTableAttributesDxe
> > > module is optional module, because a platform may use its
> own module to set
> > attributes for ACPINvs or reserved.
> > >
> > > How about we add error message when install this table in
> > DxeCore.InstallPropertiesTable().
> > > if ((mPropertiesTable.MemoryProtectionAttribute &
> > >
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA)
> ==
> > 0) {
> > >   DEBUG ((EFI_D_ERROR, "MemoryProtectionAttribute
> > NON_EXECUTABLE_PE_DATA  not set\n")); <== New line
> > >   return ;
> > > }
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of
> > > Kinney, Michael D
> > > Sent: Friday, December 04, 2015 8:27 AM
> > > To: Laszlo Ersek; Kinney, Michael D
> > > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Laszlo,
> > >
> > > That is a good question.  If a platform requires
> > >
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA
> to
> > be set, then it is an error condition.  That is why it is an
> error message and not a
> > warning message.
> > >
> > > We could consider changing this specific message to a
> warning, and add
> > > one error message from the
> > > \MdeModulePkg\Universal\PropertiesTableAttributesDxe module.
> That way, only
> > platforms that include this module will get an error message
> if any runtime modules
> > for not use 4KB aligned.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > > Sent: Thursday, December 3, 2015 3:36 PM
> > > > To: Kinney, Michael D 
> > > > Cc: Hamel, Lee M ; edk2-
> de...@lists.01.org
> > > > 
> > > > Subject: Re: [edk2] InsertImageRecord and Section
> Alignment
> > > >
> > > > On 12/03/15 21:16, Kinney, Michael D wrote:
> > > > > Lee,
> > > > >
> > > > > It is a feature from UEFI Specification 2.5 - Section
> 4.6 -
> > > > > EFI_PROPERTIES_TABLE
> > > > >
> > > > > In order to set the
> > > > >
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA
> > > > > bit, runtime drivers need to be built so their PE/COFF
> code and
> > > > > data sections do not share the same 4KB page.
> > > > >
> > > > > The log message you are seeing is not an error.  It is a
> warning
> > > > > message that a runtime driver was loaded that does not
> meet the
> > > > > requirements to set this bit.
> > > >
> > > > Should the message be downgraded from EFI_D_ERROR to
> EFI_D_WARN
> > > > ("MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c")?
> > > >
> > > > Thanks
> > > > Laszlo
> > > >
> > > > >
> > > > > Mike
> > > > >
> > > > >> -Original Message-
> > > > >> From: Hamel, Lee M
> > > > >> Sent: Thursday, December 3, 2015 11:19 AM
> > > > >> To: Kinney, Michael D 

[edk2] [Patch] QuarkPlatformPkg/SpiFvbServices: Remove duplicate global variable

[Michael Kinney]

Remove declaration of gEfiFirmwareVolumeBlockProtocolGuid and
gEfiSmmFirmwareVolumeBlockProtocolGuid that are generating build
failures on GCC because these same variables are declared in
AutoGen.c and assigned a GUID value from DEC file.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c 
b/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c
index 6d21bb0..6cfe710 100644
--- a/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c
+++ b/QuarkPlatformPkg/Platform/SpiFvbServices/FwBlockService.c
@@ -16,8 +16,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include "FwBlockService.h"
 
 ESAL_FWB_GLOBAL *mFvbModuleGlobal;
-EFI_GUID gEfiFirmwareVolumeBlockProtocolGuid;
-EFI_GUID gEfiSmmFirmwareVolumeBlockProtocolGuid;
 
 EFI_FW_VOL_BLOCK_DEVICE mFvbDeviceTemplate = {
   FVB_DEVICE_SIGNATURE,  // Signature
-- 
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 v2] MdePkg: Add missing SMBIOS definitions for SATA and SAS Ports

[Zeng, Star]

On 2015/12/16 4:44, Samer El-Haj-Mahmoud wrote:

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
  MdePkg/Include/IndustryStandard/SmBios.h | 3 +++
  1 file changed, 3 insertions(+)


Reviewed-by: Star Zeng 



diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 0959247..b7c54f2 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -2,6 +2,7 @@
Industry Standard Definitions of SMBIOS Table Specification v3.0.0.

  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 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 that accompanies this 
distribution.
  The full text of the license may be found at
@@ -1077,6 +1078,8 @@ typedef enum {
PortTypeAudioPort = 0x1D,
PortTypeModemPort = 0x1E,
PortTypeNetworkPort   = 0x1F,
+  PortTypeSata  = 0x20,
+  PortTypeSas   = 0x21,
PortType8251Compatible= 0xA0,
PortType8251FifoCompatible= 0xA1,
PortTypeOther = 0xFF



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

[edk2] [Patch] QuarkPlatformPkg/PlatformSecLib: Sync Flat32.S with Flat32.asm

[Michael Kinney]

Update Flat32.S to match Flat32.asm.  A sync was missed, so
Flat32.S is calling SecStartup instead of PlatformSecLibStartup
which is causing a boot failures with GCC builds because the
caches are not initialized correctly when the call to
PlatformSecLibStartup is not performed.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../Library/PlatformSecLib/Ia32/Flat32.S   | 29 ++
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.S 
b/QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.S
index fbdad53..2bb503f 100644
--- a/QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.S
+++ b/QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.S
@@ -1,6 +1,6 @@
 #--
 #
-# Copyright (c) 2013 Intel Corporation.
+# Copyright (c) 2013 - 2015 Intel Corporation.
 #
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
@@ -302,34 +302,9 @@ PushBist:
   loopPushBist
 
   #
-  # Pass entry point of the PEI core
-  #
-  movl $0xFFE0, %edi
-  pushl %ds:(%edi)
-
-  #
-  # Pass BFV into the PEI Core
-  #
-  movl $0xFFFC, %edi
-  pushl %ds:(%edi)
-
-  #
-  # Pass Temp Ram Base into the PEI Core
-  #
-  movlASM_PFX(PcdGet32(PcdEsramStage1Base)), %eax
-  addl$(QUARK_ESRAM_MEM_SIZE_BYTES - QUARK_STACK_SIZE_BYTES), %eax
-  pushl   %eax
-
-
-  #
-  # Pass stack size into the PEI Core
-  #
-  pushl   $QUARK_STACK_SIZE_BYTES
-
-  #
   # Pass Control into the PEI Core
   #
-  call SecStartup
+  call PlatformSecLibStartup
 
   #
   # PEI Core should never return to here, this is just to capture an invalid 
return.
-- 
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] IntelFrameworkModulePkg : Allow ACPI tables to get installed above 4GB

[Fan, Jeff]

I agree with 2). New function is better.

Jeff
-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, December 16, 2015 8:49 AM
To: Samer El-Haj-Mahmoud; edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud; Fan, Jeff
Subject: RE: [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get 
installed above 4GB

HI Samer
This mechanism is good. I like it because it brings new capability and keeps 
old compatibility at same time.

I have 2 suggestion for your consideration:
1) I guess we need similar fix for MdeModulePkg\Universal\Acpi\AcpiTableDxe.

2) Can we create a new function to allocate <4G at first, if fail, allocate any 
memory?
Then we can update all caller to consume this new function.
We can avoid adding ERROR check anywhere. I also suggest we need add some debug 
message there, we can add into one place.

Thank you
Yao Jiewen

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer 
El-Haj-Mahmoud
Sent: Wednesday, December 16, 2015 4:40 AM
To: edk2-devel@lists.01.org
Cc: Samer El-Haj-Mahmoud; Fan, Jeff
Subject: [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get 
installed above 4GB

Some ARM systems do not have available memory below 4GB, and still support 
ACPI. This patch allows the tables to get loaded above 4GB if the allocation 
below 4GB fails.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 .../AcpiSupportAcpiSupportProtocol.c   | 69 --
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
 
b/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
index 6443c3a..72a7fe1 100644
--- 
a/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportAcpiSupportProtocol.c
+++ b/IntelFrameworkModulePkg/Universal/Acpi/AcpiSupportDxe/AcpiSupportA
+++ cpiSupportProtocol.c
@@ -2,6 +2,7 @@
   ACPI Support Protocol implementation
 
 Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions @@ -533,6 +534,14 @@ ReallocateAcpiTableBuffer (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (TotalSize),
+
+);
+  }
+  if (EFI_ERROR (Status)) {
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -548,8 +557,13 @@ ReallocateAcpiTableBuffer (
   //
   // Update RSDP to point to the new Rsdt and Xsdt address.
   //
-  AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
-  AcpiSupportInstance->Rsdp3->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt3;
+  if ((UINTN) AcpiSupportInstance->Rsdt3 < BASE_4GB) {
+AcpiSupportInstance->Rsdp1->RsdtAddress = (UINT32) (UINTN) 
AcpiSupportInstance->Rsdt1;
+AcpiSupportInstance->Rsdp3->RsdtAddress = (UINT32) (UINTN) 
+ AcpiSupportInstance->Rsdt3;  } else {
+AcpiSupportInstance->Rsdp1->RsdtAddress = 0;
+AcpiSupportInstance->Rsdp3->RsdtAddress = 0;  }
   CurrentData = (UINT64) (UINTN) AcpiSupportInstance->Xsdt;
   CopyMem (>Rsdp3->XsdtAddress, , sizeof 
(UINT64));
 
@@ -669,6 +683,15 @@ AddTableToList (
 CurrentTableList->NumberOfPages,
 >PageAddress
 );
+
+if (EFI_ERROR (Status)) {
+  Status = gBS->AllocatePages (
+  AllocateAnyPages,
+  EfiACPIMemoryNVS,
+  CurrentTableList->NumberOfPages,
+  >PageAddress
+  );
+}
   } else {
 //
 // All other tables are ACPI reclaim memory, no alignment requirements.
@@ -679,6 +702,15 @@ AddTableToList (
 CurrentTableList->NumberOfPages,
 >PageAddress
 );
+
+if (EFI_ERROR (Status)) {
+  Status = gBS->AllocatePages (
+  AllocateAnyPages,
+  EfiACPIReclaimMemory,
+  CurrentTableList->NumberOfPages,
+  >PageAddress
+  );
+}
   }
   //
   // Check return value from memory alloc.
@@ -1785,6 +1817,15 @@ AcpiSupportAcpiSupportConstructor (
   );
 
   if (EFI_ERROR (Status)) {
+Status = gBS->AllocatePages (
+AllocateAnyPages,
+EfiACPIReclaimMemory,
+EFI_SIZE_TO_PAGES (RsdpTableSize),
+
+);
+  }
+
+  if (EFI_ERROR (Status)) {
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -1823,6 +1864,15 @@ AcpiSupportAcpiSupportConstructor (
   );
 
   if 

Re: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected

[El-Haj-Mahmoud, Samer]

Mike,

The issue is that even with Legacy OptionROM, most adapters that advertise 
64bit MMIO capability actually support it. We have seen instances of specific 
adapters/classes of adapters that don't work unless they get degeaded, but that 
is not usually following the generic pattern of the presence of a Legacy option 
ROM.

In fact, I am working on a seperate patch to allow a platform library of 
implementing special degradation rules for specific cards (could be a black 
list implementation for instance). That would be completely up to the platform 
to decide, with EDK2 providing a NULL library call.

We could also move the optionROM check to the platform library if you prefer.

What do you think?

Thanks
Samer



-Original Message-
From: Kinney, Michael D [michael.d.kin...@intel.com]
Received: Tuesday, 15 Dec 2015, 6:54PM
To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]; Mahan, Patrick 
[patrick.ma...@caviumnetworks.com]; edk2-devel@lists.01.org 
[edk2-devel@lists.01.org]; Kinney, Michael D [michael.d.kin...@intel.com]
Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

Samer,

Do you think it makes sense to add code to check to see if legacy option ROM 
image is present in the option ROM BAR and only degrade if that type of image 
is found.

That could avoid the introduction of a new PCD.

Thanks,

Mike

> -Original Message-
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-
> mahm...@hpe.com]
> Sent: Tuesday, December 15, 2015 10:31 AM
> To: Mahan, Patrick ; edk2-
> de...@lists.01.org; Kinney, Michael D
> 
> Cc: El-Haj-Mahmoud, Samer 
> Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when
> an option ROM is detected
>
> Patrick,
> The Patch was submitted to EDK2 list yesterday. Look for subject
> line:
>
> [PATCH] MdePkg: Add PcdPciDegradeIfOptionRomPresent PCD for PCI
> resource degradation policy
>
> Please review.
>
>  I also CC'd Mike Kinney on the review.
>
> Thanks,
> --Samer
>
>
> -Original Message-
> From: Mahan, Patrick [mailto:patrick.ma...@caviumnetworks.com]
> Sent: Tuesday, December 15, 2015 12:27 PM
> To: El-Haj-Mahmoud, Samer ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] Regarding the demotion of 64-bit BARs when
> an option ROM is detected
>
> Greetings Samer,
>
> I would like to see this patch implemented.  Part of the issue I
> am wrestling with on our AARCH64 platform is how our PCIe's are
> supported.  In our current architecture, we can have up to 6
> PCIe's connected through two Switch Logic Interfaces (SLI) that
> must be programmed correctly.  Part of this is the BAR address
> that is in use which depends heavily on the BAR type.  What we
> are seeing is that the BAR type is being demoted to 32-bit which
> causes us to program the SLI for 32-bit access.  But the PCIe
> device is 64-bit and attempts to use 64-bit addressing which
> fails.
>
> A PCD that can be configured to disable the demotion based on
> the presence of an option ROM would be greatly appreciated.
> Then the code in DegradeResource() could simply check to see if
> it needed to enforce this demotion or not.
>
> I can understand if this were a legacy BIOS image as this
> currently seems (to me) to limit option ROM drivers to be 32-bit
> only.
>
> As I stated below, I currently have it commented out and this is
> allowing our SLI's to be programmed correctly.
>
> I'll be glad to review the patch when you have it ready.
>
> Thanks,
>
> Patrick
>
> 
> From: El-Haj-Mahmoud, Samer 
> Sent: Monday, December 14, 2015 3:35 PM
> To: Mahan, Patrick; edk2-devel@lists.01.org
> Cc: El-Haj-Mahmoud, Samer
> Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when
> an option ROM is detected
>
> Hello Patrick,
>
> We ran into the same issue of automatic demoation simply because
> of the presence of an OptionROM. We believe this is an overly
> aggressive policy. In fact, I have a patch that I am about to
> submit that adds a platform PCD to enable/disable this policy.
>
> Would like feedback on the idea as well as the patch.
>
> Thanks,
> --Samer
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Mahan, Patrick
> Sent: Monday, December 14, 2015 4:13 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Regarding the demotion of 64-bit BARs when an
> option ROM is detected
>
> All,
>
> I am working on writing the UEFI driver for our LiquidIO line of
> NICs and have run into an issue with the PCI layer that may or
> may not be contributing.
>
> I am working with our AARCH64 platform, ThunderX and in the
> handling of the PCIe detection.  The code that handles the PCI
> configuration on ThunderX requires knowing the resource type of
> a BAR (IO16, IO32, MEM32/PMEM32, MEM64/PMEM64).
>
> There is an 

Re: [edk2] InsertImageRecord and Section Alignment

[Kinney, Michael D]

Baranee,

I see that error message if a PE/COFF image is stored in TE format or is XIP 
PE/COFF image.

In general, modules of type DXE_RUNTIME_DRIVER are not expected to use TE or be 
XIP.

Here is an example FDF file FFS rule for modules of type DXE_RUNTIME_DRIVER.  
It uses PE32 (not TE) and it does not strip the relocations.

[Rule.Common.DXE_RUNTIME_DRIVER]
  FILE DRIVER = $(NAMED_GUID) {
DXE_DEPEX DXE_DEPEX Optional   $(INF_OUTPUT)/$(MODULE_NAME).depex
PE32  PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
UISTRING="$(MODULE_NAME)" Optional
VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }

Are you using a different rule?

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Anbazhagan, Baraneedharan
> Sent: Tuesday, December 15, 2015 5:07 PM
> To: Kinney, Michael D ; Yao, Jiewen
> ; Laszlo Ersek 
> Cc: Hamel, Lee M ; Barlow, Dallas
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Hi Mike,
> Am using the same build flag that you mentioned and getting the
> build error - 'Section-Alignment and File-Alignment do not match
> :.ffs'
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> 
> Thanks,
> Baranee
> 
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Tuesday, December 15, 2015 6:57 PM
> > To: Anbazhagan, Baraneedharan ; Yao, Jiewen
> > ; Laszlo Ersek ;
> Kinney, Michael D
> > 
> > Cc: Hamel, Lee M ; Barlow, Dallas
> > ; edk2-devel@lists.01.org  de...@ml01.01.org>
> > Subject: RE: [edk2] InsertImageRecord and Section Alignment
> >
> > Baranee,
> >
> > What build flags are you using?
> >
> > Most platforms can add the following in their DSC file to get
> this to work form
> > VS20xx tool chains.
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of
> > > Anbazhagan, Baraneedharan
> > > Sent: Tuesday, December 15, 2015 8:31 AM
> > > To: Kinney, Michael D ; Yao,
> Jiewen
> > > ; Laszlo Ersek 
> > > Cc: Hamel, Lee M ; Barlow, Dallas
> > > ; edk2-devel@lists.01.org  > > de...@ml01.01.org>
> > > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Hi,
> > > When I tried to enable section alignment in DSC for Runtime
> modules,
> > > am getting a build error that section alignment and file
> alignment
> > > doesn't match(GenFvInternalLib.c). Am using
> > > VS2012x86 build tools. Whether any other build flag needs to
> be set?
> > >
> > > - Baranee
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On
> > > Behalf Of Kinney,
> > > > Michael D
> > > > Sent: Monday, December 07, 2015 8:23 PM
> > > > To: Yao, Jiewen; Laszlo Ersek; Kinney, Michael D
> > > > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > > > Subject: Re: [edk2] InsertImageRecord and Section
> Alignment
> > > >
> > > > Jiewen,
> > > >
> > > > I agree that is a good place to put the error message.
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Yao, Jiewen
> > > > > Sent: Sunday, December 6, 2015 7:06 PM
> > > > > To: Kinney, Michael D ;
> Laszlo
> > > Ersek
> > > > > ; Kinney, Michael D
> > > 
> > > > > Cc: Hamel, Lee M ; edk2-
> > > de...@lists.01.org
> > > > > 
> > > > > Subject: RE: [edk2] InsertImageRecord and Section
> Alignment
> > > > >
> > > > > Hi Mike
> > > > > I agree that we can change this from ERROR to WARNING,
> and
> > > only add 1 ERROR
> > > > message.
> > > > >
> > > > > However, the
> > > \MdeModulePkg\Universal\PropertiesTableAttributesDxe
> > > > > module is optional module, because a platform may use
> its
> > > own module to set
> > > > attributes for ACPINvs or reserved.
> > > > >
> > > > > How about we add error message when install this table
> in
> > > > DxeCore.InstallPropertiesTable().
> > > > > if ((mPropertiesTable.MemoryProtectionAttribute &
> > > > >
> > >
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA)
> > > ==
> > > > 0) {
> > > > >   DEBUG ((EFI_D_ERROR, "MemoryProtectionAttribute
> > > > NON_EXECUTABLE_PE_DATA  not set\n")); <== New line
> > > > >   return ;
> > > > > }
> > > > >
> > > > > Thank you
> > > > > Yao Jiewen
> > 

Re: [edk2] InsertImageRecord and Section Alignment

[Gao, Liming]

Normally, DXE Runtime driver will not be rebased unless you expect it to run as 
XIP. Is it your expectation? If not, you can configure FvForceRebase=FALSE to 
disable rebase in FV that includes runtime drivers. 

[FV.DXEFV]
BlockSize  = 0x1000
FvForceRebase = FALSE  # add this line
FvAlignment= 16

INF DxeRuntimeDriver.inf # Runtime Driver

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Anbazhagan, Baraneedharan
Sent: Wednesday, December 16, 2015 10:23 AM
To: Kinney, Michael D; Yao, Jiewen; Laszlo Ersek
Cc: Hamel, Lee M; Barlow, Dallas; edk2-devel@lists.01.org
Subject: Re: [edk2] InsertImageRecord and Section Alignment

Am using the same rules. Similar error message is used in 
BaseTools\Source\C\GenFv\GenFvInternalLib.c - FfsRebase() as well and it checks 
for driver type. Both DXE driver and DXE_RUNTIME_DRIVER uses same driver type - 
0x07

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Tuesday, December 15, 2015 7:44 PM
> To: Anbazhagan, Baraneedharan ; Yao, Jiewen 
> ; Laszlo Ersek ; Kinney, 
> Michael D 
> Cc: Hamel, Lee M ; Barlow, Dallas 
> ; edk2-devel@lists.01.org 
> 
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Baranee,
> 
> I see that error message if a PE/COFF image is stored in TE format or 
> is XIP PE/COFF image.
> 
> In general, modules of type DXE_RUNTIME_DRIVER are not expected to use 
> TE or be XIP.
> 
> Here is an example FDF file FFS rule for modules of type 
> DXE_RUNTIME_DRIVER.  It uses PE32 (not TE) and it does not strip the 
> relocations.
> 
> [Rule.Common.DXE_RUNTIME_DRIVER]
>   FILE DRIVER = $(NAMED_GUID) {
> DXE_DEPEX DXE_DEPEX Optional   $(INF_OUTPUT)/$(MODULE_NAME).depex
> PE32  PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
> UISTRING="$(MODULE_NAME)" Optional
> VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
>   }
> 
> Are you using a different rule?
> 
> Mike
> 
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Anbazhagan, Baraneedharan
> > Sent: Tuesday, December 15, 2015 5:07 PM
> > To: Kinney, Michael D ; Yao, Jiewen 
> > ; Laszlo Ersek 
> > Cc: Hamel, Lee M ; Barlow, Dallas 
> > ; edk2-devel@lists.01.org  > de...@ml01.01.org>
> > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> >
> > Hi Mike,
> > Am using the same build flag that you mentioned and getting the 
> > build error - 'Section-Alignment and File-Alignment do not match 
> > :.ffs'
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >
> > Thanks,
> > Baranee
> >
> > > -Original Message-
> > > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > > Sent: Tuesday, December 15, 2015 6:57 PM
> > > To: Anbazhagan, Baraneedharan ; Yao, Jiewen 
> > > ; Laszlo Ersek ;
> > Kinney, Michael D
> > > 
> > > Cc: Hamel, Lee M ; Barlow, Dallas 
> > > ; edk2-devel@lists.01.org  > de...@ml01.01.org>
> > > Subject: RE: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Baranee,
> > >
> > > What build flags are you using?
> > >
> > > Most platforms can add the following in their DSC file to get
> > this to work form
> > > VS20xx tool chains.
> > >
> > > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> > >   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > Behalf Of
> > > > Anbazhagan, Baraneedharan
> > > > Sent: Tuesday, December 15, 2015 8:31 AM
> > > > To: Kinney, Michael D ; Yao,
> > Jiewen
> > > > ; Laszlo Ersek 
> > > > Cc: Hamel, Lee M ; Barlow, Dallas 
> > > > ; edk2-devel@lists.01.org  > > > de...@ml01.01.org>
> > > > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> > > >
> > > > Hi,
> > > > When I tried to enable section alignment in DSC for Runtime
> > modules,
> > > > am getting a build error that section alignment and file
> > alignment
> > > > doesn't match(GenFvInternalLib.c). Am using
> > > > VS2012x86 build tools. Whether any other build flag needs to
> > be set?
> > > >
> > > > - Baranee
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> > On
> > > > Behalf Of Kinney,
> > > > > Michael D
> > 

Re: [edk2] [Patch] edk2: Add maintainers for Quark*Pkg

[Jordan Justen]

I kind of prefer using Maintainers.txt for the subject prefix, but
edk2 seems okay as well:

Maintainers.txt: Add maintainers for Quark*Pkg

On 2015-12-15 09:26:16, Michael Kinney wrote:
> Add maintaintainers for the QuarkSocPkg and QuarkPlatformPkg
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
>  Maintainers.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index acb717e..cb981b6 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -175,6 +175,14 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/PerformancePkg
>  M: Daryl McDaniel 
>  M: Jaben Carsey 
>  
> +QuarkSocPkg
> +M: Michael Kinney 

You have a space in your email address.

I put your middle initial in other places in this file, but that was
because I wasn't sure what your preference was.

> +M: Kelly Steele 
> +
> +QuarkPlatformPkg

These two aren't in alphabetical order.

In some cases we've put multiple packages together where they had the
same maintainers (See FatPkg, ShellPkg, etc). I'm not sure if that
would be useful here.

-Jordan

> +M: Michael Kinney 
> +M: Kelly Steele 
> +
>  SecurityPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SecurityPkg
>  M: Chao Zhang 
> -- 
> 2.6.3.windows.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] [Patch] MdeModulePkg: Update print error level for RuntimeDriver alignment check

[Liming Gao]

In DxeCore, use warning message for Runtime driver that doesn't satisfy
section alignment requirement. This check is required when PropertiesTable
is installed. So, add error message if PropertiesTable can't be installed
successfully.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index 3486737..adfc91c 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -1120,11 +1120,11 @@ InsertImageRecord (
 
   SetPropertiesTableSectionAlignment (SectionAlignment);
   if ((SectionAlignment & (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) != 
0) {
-DEBUG ((EFI_D_ERROR, "  InsertImageRecord - Section 
Alignment(0x%x) is not %dK  \n",
+DEBUG ((EFI_D_WARN, "  InsertImageRecord - Section Alignment(0x%x) 
is not %dK  \n",
   SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
 PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
 if (PdbPointer != NULL) {
-  DEBUG ((EFI_D_ERROR, "  Image - %a  \n", PdbPointer));
+  DEBUG ((EFI_D_WARN, "  Image - %a  \n", PdbPointer));
 }
 goto Finish;
   }
@@ -1320,6 +1320,8 @@ InstallPropertiesTable (
 
 DEBUG ((EFI_D_INFO, "MemoryProtectionAttribute - 0x%016lx\n", 
mPropertiesTable.MemoryProtectionAttribute));
 if ((mPropertiesTable.MemoryProtectionAttribute & 
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA) == 0) {
+  DEBUG ((EFI_D_ERROR, "MemoryProtectionAttribute NON_EXECUTABLE_PE_DATA 
is not set, "));
+  DEBUG ((EFI_D_ERROR, "because Runtime Driver Section Alignment is not 
%dK.\n", EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
   return ;
 }
 
-- 
1.9.5.msysgit.0

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

Re: [edk2] [Patch] MdeModulePkg: Update print error level for RuntimeDriver alignment check

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Wednesday, December 16, 2015 1:05 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] MdeModulePkg: Update print error level for 
RuntimeDriver alignment check

In DxeCore, use warning message for Runtime driver that doesn't satisfy section 
alignment requirement. This check is required when PropertiesTable is 
installed. So, add error message if PropertiesTable can't be installed 
successfully.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index 3486737..adfc91c 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -1120,11 +1120,11 @@ InsertImageRecord (
 
   SetPropertiesTableSectionAlignment (SectionAlignment);
   if ((SectionAlignment & (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) != 
0) {
-DEBUG ((EFI_D_ERROR, "  InsertImageRecord - Section 
Alignment(0x%x) is not %dK  \n",
+DEBUG ((EFI_D_WARN, "  InsertImageRecord - Section 
+ Alignment(0x%x) is not %dK  \n",
   SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
 PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
 if (PdbPointer != NULL) {
-  DEBUG ((EFI_D_ERROR, "  Image - %a  \n", PdbPointer));
+  DEBUG ((EFI_D_WARN, "  Image - %a  \n", 
+ PdbPointer));
 }
 goto Finish;
   }
@@ -1320,6 +1320,8 @@ InstallPropertiesTable (
 
 DEBUG ((EFI_D_INFO, "MemoryProtectionAttribute - 0x%016lx\n", 
mPropertiesTable.MemoryProtectionAttribute));
 if ((mPropertiesTable.MemoryProtectionAttribute & 
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA) == 0) {
+  DEBUG ((EFI_D_ERROR, "MemoryProtectionAttribute NON_EXECUTABLE_PE_DATA 
is not set, "));
+  DEBUG ((EFI_D_ERROR, "because Runtime Driver Section Alignment is 
+ not %dK.\n", EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
   return ;
 }
 
--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 2/3] ArmVExpressPkg/ArmVExpress-FVP-AArch64: run GICv3 in v3 mode

[Leif Lindholm]

On Thu, Dec 03, 2015 at 02:58:37PM +0100, Ard Biesheuvel wrote:
> After fixing ArmGicEnableDistributor() in a previous patch, there is no
> longer a reason to run the GICv3 in v2 mode, so remove the PCD override.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

I think there could be interaction issues with certain versions of ARM
Trusted Firmware, but this just flips the default, and I'm happy for
anyone running into issues to have to add an option for their
platform.

Reviewed-by: Leif Lindholm 

> ---
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
> index f82de7e07de7..af46331052a4 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
> @@ -74,12 +74,6 @@ [PcdsFeatureFlag.common]
>#  It could be set FALSE to save size.
>gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
>  
> -  # Force the UEFI GIC driver to use GICv2 legacy mode. To use
> -  # GICv3 without GICv2 legacy in UEFI, the ARM Trusted Firmware needs
> -  # to configure the Non-Secure interrupts in the GIC Redistributors
> -  # which is not supported at the moment.
> -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|TRUE
> -
>  [PcdsFixedAtBuild.common]
>gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Fixed Virtual Platform"
>gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ARM-FVP"
> -- 
> 1.9.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] ArmPkg/ArmGic: remove GICv3 legacy override

[Ard Biesheuvel]

On 15 December 2015 at 13:45, Leif Lindholm  wrote:
>
> On Thu, Dec 03, 2015 at 02:58:38PM +0100, Ard Biesheuvel wrote:
> > The need for a v2 legacy override to drive a GICv3 in v2 mode is no
> > longer necessary, now that the code that enabled the GIC distributor no
> > longer inadvertently kicks a v2 capable GICv3 into v2 mode. So remove
> > the PCD and all references to it.
>
> For reasons stated in comment to previous patch, I'd like to hold off
> on completely dropping this code for now. But keep it around for
> future.
>

OK, fair enough. I pushed #1 and #2 as SVN r19274 and r19275, respectively.


> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  ArmPkg/ArmPkg.dec |  3 --
> >  ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  1 -
> >  ArmPkg/Drivers/ArmGic/ArmGicLib.c |  6 ++--
> >  ArmPkg/Drivers/ArmGic/ArmGicLib.inf   |  3 --
> >  ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf|  3 --
> >  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 35 
> >  6 files changed, 9 insertions(+), 42 deletions(-)
> >
> > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> > index ff4531e44106..e8021d20bc78 100644
> > --- a/ArmPkg/ArmPkg.dec
> > +++ b/ArmPkg/ArmPkg.dec
> > @@ -70,9 +70,6 @@ [PcdsFeatureFlag.common]
> ># Linux (instead of PSCI)
> >gArmTokenSpaceGuid.PcdArmLinuxSpinTable|FALSE|BOOLEAN|0x0033
> >
> > -  # Define if the GICv3 controller should use the GICv2 legacy
> > -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE|BOOLEAN|0x0042
> > -
> >  [PcdsFeatureFlag.ARM]
> ># Whether to map normal memory as non-shareable. FALSE is the safe 
> > choice, but
> ># TRUE may be appropriate to fix performance problems if you don't care 
> > about
> > diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf 
> > b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> > index e554301c4b28..31d90a6d473d 100644
> > --- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> > +++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> > @@ -54,7 +54,6 @@ [Pcd.common]
> >gArmTokenSpaceGuid.PcdGicDistributorBase
> >gArmTokenSpaceGuid.PcdGicRedistributorsBase
> >gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
> > -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
> >
> >  [Depex]
> >gEfiCpuArchProtocolGuid
> > diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
> > b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > index 248e896c4b94..f218a8d7ef06 100644
> > --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> > @@ -183,7 +183,7 @@ ArmGicEnableInterrupt (
> >RegShift = Source % 32;
> >
> >Revision = ArmGicGetSupportedArchRevision ();
> > -  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
> > (PcdArmGicV3WithV2Legacy)) {
> > +  if (Revision == ARM_GIC_ARCH_REVISION_2) {
> >  // Write set-enable register
> >  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * RegOffset), 1 
> > << RegShift);
> >} else {
> > @@ -216,7 +216,7 @@ ArmGicDisableInterrupt (
> >RegShift = Source % 32;
> >
> >Revision = ArmGicGetSupportedArchRevision ();
> > -  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
> > (PcdArmGicV3WithV2Legacy)) {
> > +  if (Revision == ARM_GIC_ARCH_REVISION_2) {
> >  // Write clear-enable register
> >  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDICER + (4 * RegOffset), 1 
> > << RegShift);
> >} else {
> > @@ -249,7 +249,7 @@ ArmGicIsInterruptEnabled (
> >RegShift = Source % 32;
> >
> >Revision = ArmGicGetSupportedArchRevision ();
> > -  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
> > (PcdArmGicV3WithV2Legacy)) {
> > +  if (Revision == ARM_GIC_ARCH_REVISION_2) {
> >  Interrupts = ((MmioRead32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * 
> > RegOffset)) & (1 << RegShift)) != 0);
> >} else {
> >  GicCpuRedistributorBase = GicGetCpuRedistributorBase 
> > (GicRedistributorBase, Revision);
> > diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf 
> > b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> > index 047adac85ff4..62f20eb55294 100644
> > --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> > +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> > @@ -46,6 +46,3 @@ [Packages]
> >
> >  [Pcd]
> >gArmPlatformTokenSpaceGuid.PcdCoreCount
> > -
> > -[FeaturePcd]
> > -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
> > diff --git a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf 
> > b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
> > index fc2e1bc01efe..efea9c828170 100644
> > --- a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
> > +++ b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
> > @@ -47,6 +47,3 @@ [LibraryClasses]
> >
> >  [Pcd]
> >gArmPlatformTokenSpaceGuid.PcdCoreCount
> > -
> > -[FeaturePcd]
> > -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
> > diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
> > b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> > index 4afa3d5a09c2..0a75850200bd 100644
> > --- 

Re: [edk2] [PATCH 3/3] ArmPkg/ArmGic: remove GICv3 legacy override

[Leif Lindholm]

On Thu, Dec 03, 2015 at 02:58:38PM +0100, Ard Biesheuvel wrote:
> The need for a v2 legacy override to drive a GICv3 in v2 mode is no
> longer necessary, now that the code that enabled the GIC distributor no
> longer inadvertently kicks a v2 capable GICv3 into v2 mode. So remove
> the PCD and all references to it.

For reasons stated in comment to previous patch, I'd like to hold off
on completely dropping this code for now. But keep it around for
future.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dec |  3 --
>  ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  1 -
>  ArmPkg/Drivers/ArmGic/ArmGicLib.c |  6 ++--
>  ArmPkg/Drivers/ArmGic/ArmGicLib.inf   |  3 --
>  ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf|  3 --
>  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 35 
>  6 files changed, 9 insertions(+), 42 deletions(-)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index ff4531e44106..e8021d20bc78 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -70,9 +70,6 @@ [PcdsFeatureFlag.common]
># Linux (instead of PSCI)
>gArmTokenSpaceGuid.PcdArmLinuxSpinTable|FALSE|BOOLEAN|0x0033
>  
> -  # Define if the GICv3 controller should use the GICv2 legacy
> -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE|BOOLEAN|0x0042
> -
>  [PcdsFeatureFlag.ARM]
># Whether to map normal memory as non-shareable. FALSE is the safe choice, 
> but
># TRUE may be appropriate to fix performance problems if you don't care 
> about
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf 
> b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> index e554301c4b28..31d90a6d473d 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> @@ -54,7 +54,6 @@ [Pcd.common]
>gArmTokenSpaceGuid.PcdGicDistributorBase
>gArmTokenSpaceGuid.PcdGicRedistributorsBase
>gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
> -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
>  
>  [Depex]
>gEfiCpuArchProtocolGuid
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
> b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> index 248e896c4b94..f218a8d7ef06 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> @@ -183,7 +183,7 @@ ArmGicEnableInterrupt (
>RegShift = Source % 32;
>  
>Revision = ArmGicGetSupportedArchRevision ();
> -  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
> (PcdArmGicV3WithV2Legacy)) {
> +  if (Revision == ARM_GIC_ARCH_REVISION_2) {
>  // Write set-enable register
>  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * RegOffset), 1 
> << RegShift);
>} else {
> @@ -216,7 +216,7 @@ ArmGicDisableInterrupt (
>RegShift = Source % 32;
>  
>Revision = ArmGicGetSupportedArchRevision ();
> -  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
> (PcdArmGicV3WithV2Legacy)) {
> +  if (Revision == ARM_GIC_ARCH_REVISION_2) {
>  // Write clear-enable register
>  MmioWrite32 (GicDistributorBase + ARM_GIC_ICDICER + (4 * RegOffset), 1 
> << RegShift);
>} else {
> @@ -249,7 +249,7 @@ ArmGicIsInterruptEnabled (
>RegShift = Source % 32;
>  
>Revision = ArmGicGetSupportedArchRevision ();
> -  if ((Revision == ARM_GIC_ARCH_REVISION_2) || FeaturePcdGet 
> (PcdArmGicV3WithV2Legacy)) {
> +  if (Revision == ARM_GIC_ARCH_REVISION_2) {
>  Interrupts = ((MmioRead32 (GicDistributorBase + ARM_GIC_ICDISER + (4 * 
> RegOffset)) & (1 << RegShift)) != 0);
>} else {
>  GicCpuRedistributorBase = GicGetCpuRedistributorBase 
> (GicRedistributorBase, Revision);
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf 
> b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> index 047adac85ff4..62f20eb55294 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> @@ -46,6 +46,3 @@ [Packages]
>  
>  [Pcd]
>gArmPlatformTokenSpaceGuid.PcdCoreCount
> -
> -[FeaturePcd]
> -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf 
> b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
> index fc2e1bc01efe..efea9c828170 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
> @@ -47,6 +47,3 @@ [LibraryClasses]
>  
>  [Pcd]
>gArmPlatformTokenSpaceGuid.PcdCoreCount
> -
> -[FeaturePcd]
> -  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy
> diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
> b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> index 4afa3d5a09c2..0a75850200bd 100644
> --- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> +++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
> @@ -254,9 +254,7 @@ GicV3DxeInitialize (
>// We will be driving this GIC in native v3 mode, i.e., with Affinity
>// Routing enabled. So ensure that the ARE bit is set.
>//
> -  if (!FeaturePcdGet (PcdArmGicV3WithV2Legacy)) {
> -MmioOr32 (mGicDistributorBase + 

[edk2] [PATCH v2] MdePkg: Add missing SMBIOS definitions for SATA and SAS Ports

[Samer El-Haj-Mahmoud]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/IndustryStandard/SmBios.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 0959247..b7c54f2 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -2,6 +2,7 @@
   Industry Standard Definitions of SMBIOS Table Specification v3.0.0.
 
 Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2015 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 that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -1077,6 +1078,8 @@ typedef enum {
   PortTypeAudioPort = 0x1D,
   PortTypeModemPort = 0x1E,
   PortTypeNetworkPort   = 0x1F,
+  PortTypeSata  = 0x20,
+  PortTypeSas   = 0x21,
   PortType8251Compatible= 0xA0,
   PortType8251FifoCompatible= 0xA1,
   PortTypeOther = 0xFF
-- 
2.6.3.windows.1

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

Re: [edk2] InsertImageRecord and Section Alignment

[Anbazhagan, Baraneedharan]

Am using the same rules. Similar error message is used in 
BaseTools\Source\C\GenFv\GenFvInternalLib.c - FfsRebase() as well and it checks 
for driver type. Both DXE driver and DXE_RUNTIME_DRIVER uses same driver type - 
0x07

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney,
> Michael D
> Sent: Tuesday, December 15, 2015 7:44 PM
> To: Anbazhagan, Baraneedharan ; Yao, Jiewen
> ; Laszlo Ersek ; Kinney, Michael D
> 
> Cc: Hamel, Lee M ; Barlow, Dallas
> ; edk2-devel@lists.01.org 
> Subject: Re: [edk2] InsertImageRecord and Section Alignment
> 
> Baranee,
> 
> I see that error message if a PE/COFF image is stored in TE format or is XIP 
> PE/COFF
> image.
> 
> In general, modules of type DXE_RUNTIME_DRIVER are not expected to use TE or 
> be
> XIP.
> 
> Here is an example FDF file FFS rule for modules of type DXE_RUNTIME_DRIVER.  
> It
> uses PE32 (not TE) and it does not strip the relocations.
> 
> [Rule.Common.DXE_RUNTIME_DRIVER]
>   FILE DRIVER = $(NAMED_GUID) {
> DXE_DEPEX DXE_DEPEX Optional   $(INF_OUTPUT)/$(MODULE_NAME).depex
> PE32  PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
> UISTRING="$(MODULE_NAME)" Optional
> VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
>   }
> 
> Are you using a different rule?
> 
> Mike
> 
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Anbazhagan, Baraneedharan
> > Sent: Tuesday, December 15, 2015 5:07 PM
> > To: Kinney, Michael D ; Yao, Jiewen
> > ; Laszlo Ersek 
> > Cc: Hamel, Lee M ; Barlow, Dallas
> > ; edk2-devel@lists.01.org  > de...@ml01.01.org>
> > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> >
> > Hi Mike,
> > Am using the same build flag that you mentioned and getting the build
> > error - 'Section-Alignment and File-Alignment do not match : > module path>.ffs'
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> >
> > Thanks,
> > Baranee
> >
> > > -Original Message-
> > > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > > Sent: Tuesday, December 15, 2015 6:57 PM
> > > To: Anbazhagan, Baraneedharan ; Yao, Jiewen
> > > ; Laszlo Ersek ;
> > Kinney, Michael D
> > > 
> > > Cc: Hamel, Lee M ; Barlow, Dallas
> > > ; edk2-devel@lists.01.org  > de...@ml01.01.org>
> > > Subject: RE: [edk2] InsertImageRecord and Section Alignment
> > >
> > > Baranee,
> > >
> > > What build flags are you using?
> > >
> > > Most platforms can add the following in their DSC file to get
> > this to work form
> > > VS20xx tool chains.
> > >
> > > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> > >   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > Behalf Of
> > > > Anbazhagan, Baraneedharan
> > > > Sent: Tuesday, December 15, 2015 8:31 AM
> > > > To: Kinney, Michael D ; Yao,
> > Jiewen
> > > > ; Laszlo Ersek 
> > > > Cc: Hamel, Lee M ; Barlow, Dallas
> > > > ; edk2-devel@lists.01.org  > > > de...@ml01.01.org>
> > > > Subject: Re: [edk2] InsertImageRecord and Section Alignment
> > > >
> > > > Hi,
> > > > When I tried to enable section alignment in DSC for Runtime
> > modules,
> > > > am getting a build error that section alignment and file
> > alignment
> > > > doesn't match(GenFvInternalLib.c). Am using
> > > > VS2012x86 build tools. Whether any other build flag needs to
> > be set?
> > > >
> > > > - Baranee
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> > On
> > > > Behalf Of Kinney,
> > > > > Michael D
> > > > > Sent: Monday, December 07, 2015 8:23 PM
> > > > > To: Yao, Jiewen; Laszlo Ersek; Kinney, Michael D
> > > > > Cc: Hamel, Lee M; edk2-devel@lists.01.org
> > > > > Subject: Re: [edk2] InsertImageRecord and Section
> > Alignment
> > > > >
> > > > > Jiewen,
> > > > >
> > > > > I agree that is a good place to put the error message.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -Original Message-
> > > > > > From: Yao, Jiewen
> > > > > > Sent: Sunday, December 6, 2015 7:06 PM
> > > > > > To: Kinney, Michael D ;
> > Laszlo
> > > > Ersek
> > > > > > ; Kinney, Michael D
> > > > 
> > > > > > Cc: Hamel, Lee M 

Re: [edk2] [Patch v2] BootManagerLib: Check the pointer to avoid use NULL pointer.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Dong
Sent: Wednesday, December 16, 2015 11:01 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch v2] BootManagerLib: Check the pointer to avoid use NULL 
pointer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Library/BootManagerLib/BootManager.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/Library/BootManagerLib/BootManager.c 
b/MdeModulePkg/Library/BootManagerLib/BootManager.c
index cfeedeb..dd87250 100644
--- a/MdeModulePkg/Library/BootManagerLib/BootManager.c
+++ b/MdeModulePkg/Library/BootManagerLib/BootManager.c
@@ -325,10 +325,13 @@ GroupMultipleLegacyBootOption4SameType (
   EFI_BOOT_MANAGER_LOAD_OPTION BootOption;
 
   SetMem (DeviceTypeIndex, sizeof (DeviceTypeIndex), 0xff);
 
   GetEfiGlobalVariable2 (L"BootOrder", (VOID **) , );
+  if (BootOrder == NULL) {
+return;
+  }
 
   for (Index = 0; Index < BootOrderSize / sizeof (UINT16); Index++) {
 UnicodeSPrint (OptionName, sizeof (OptionName), L"Boot%04x", 
BootOrder[Index]);
 Status = EfiBootManagerVariableToLoadOption (OptionName, );
 ASSERT_EFI_ERROR (Status);
-- 
2.6.4.windows.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] [PATCH v2 1/5] ArmPkg: use unified asm syntax for CLANG

[Ard Biesheuvel]

The CLANG assembler does not support the legacy, non-unified assembler syntax,
i.e., it does not support the reordering of the condition suffixes with the
increment/decrement before/after or byte/word suffixes, and it does not
recognize the 'empty descending' (ED) suffix at all. So move to the unified
syntax, and replace 'empty descending' with 'decrement after' or 'increment
before' as appropriate.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S  |  9 
+
 ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S  |  3 ++-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S   |  5 +++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S   |  1 +
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S|  5 +++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switchu8.S   |  5 +++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/udivmoddi4.S | 11 
++-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/udivsi3.S|  3 ++-
 ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S |  9 
+
 9 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S 
b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
index 3433b99cd4d4..673b93129736 100644
--- a/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
+++ b/ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S
@@ -60,6 +60,7 @@ GCC_ASM_EXPORT(AsmCommonExceptionEntry)
 GCC_ASM_EXPORT(CommonCExceptionHandler)
 
 .text
+.syntax unified
 #if !defined(__APPLE__)
 .fpu neon@ makes vpush/vpop assemble
 #endif
@@ -223,9 +224,9 @@ ASM_PFX(AsmCommonExceptionEntry):
   and   R3, R1, #0x1f   @ Check CPSR to see if User or System Mode
   cmp   R3, #0x1f   @ if ((CPSR == 0x10) || (CPSR == 0x1f))
   cmpne R3, #0x10   @
-  stmeqed   R2, {lr}^   @   save unbanked lr
+  stmdaeq   R2, {lr}^   @   save unbanked lr
 @ else
-  stmneed   R2, {lr}@   save SVC lr
+  stmdane   R2, {lr}@   save SVC lr
 
 
   ldr   R5, [SP, #0x58] @ PC is the LR pushed by srsfd
@@ -290,9 +291,9 @@ CommonCExceptionHandler (
   and   R1, R1, #0x1f   @ Check to see if User or System Mode
   cmp   R1, #0x1f   @ if ((CPSR == 0x10) || (CPSR == 0x1f))
   cmpne R1, #0x10   @
-  ldmeqed   R2, {lr}^   @   restore unbanked lr
+  ldmibeq   R2, {lr}^   @   restore unbanked lr
 @ else
-  ldmneed   R3, {lr}@   restore SVC lr, via ldmfd SP!, {LR}
+  ldmibne   R3, {lr}@   restore SVC lr, via ldmfd SP!, {LR}
 
   ldmfd SP!,{R0-R12}@ Restore general purpose registers
 @ Exception handler can not change SP
diff --git a/ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S 
b/ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S
index c5b4cfe15f2f..970d030ca368 100755
--- a/ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S
+++ b/ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S
@@ -36,6 +36,7 @@ InternalMemSetMem (
 **/
 
 .text
+.syntax unified
 .align 2
 GCC_ASM_EXPORT(InternalMemSetMem)
 
@@ -67,7 +68,7 @@ L31:
   b  L32
 L34:
   cmp  lr, #0
-  streqb  r2, [r12], #1
+  strbeq  r2, [r12], #1
   subeqr1, r1, #1
   beq  L43
   sub  r1, r1, #32
diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S 
b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S
index 7f41353e0177..09c9004ddfff 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S
@@ -14,6 +14,7 @@
 #
 
 .text
+.syntax unified
 .p2align 2
 
 GCC_ASM_EXPORT(__switch16)
@@ -22,9 +23,9 @@ ASM_PFX(__switch16):
 ldrh  ip, [lr, #-1]
 cmp   r0, ip
 add   r0, lr, r0, lsl #1
-ldrccsh   r0, [r0, #1]
+ldrshcc   r0, [r0, #1]
 add   ip, lr, ip, lsl #1
-ldrcssh   r0, [ip, #1]
+ldrshcs   r0, [ip, #1]
 add   ip, lr, r0, lsl #1
 bxip
 
diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S 
b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S
index 8675a4aeb747..5b8fd34733cd 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S
@@ -14,6 +14,7 @@
 #
 
 .text
+.syntax unified
 .p2align 2
 
 GCC_ASM_EXPORT(__switch32)
diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S 
b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S
index 27edccbf77d0..871c7c05f7a4 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S
@@ -14,6 +14,7 @@
 #
 
 .text
+.syntax unified
 

[edk2] [PATCH v2 2/5] ArmPkg/CompilerIntrinsicsLib: add GCC version of __aeabi_memset()

[Ard Biesheuvel]

CLANG for ARM may emit calls to __aeabi_memset(), which is subtly different
from the default memset() [arguments 2 and 3 are reversed]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S 
b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
index 0c7789eb5816..bb75d7a70b80 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
@@ -15,8 +15,23 @@
 
 
   .text
+  .syntax unified
   .align 2
   GCC_ASM_EXPORT (memset)
+  GCC_ASM_EXPORT (__aeabi_memset)
+
+# VOID
+# EFIAPI
+# __aeabi_memset (
+#  IN  VOID*Destination,
+#  IN  UINT32  Size
+#  IN  UINT32  Character,
+#  );
+ASM_PFX(__aeabi_memset):
+  subs  ip, r1, #0
+  bxeq  lr
+  mov   r1, r2
+  b L10
 
 # VOID
 # EFIAPI
@@ -26,13 +41,13 @@
 #  IN  UINT32  Size
 #  );
 ASM_PFX(memset):
-  cmp  r2, #0
+  subs ip, r2, #0
   bxeq lr
   @ args = 0, pretend = 0, frame = 0
   @ frame_needed = 1, uses_anonymous_args = 0
 L10:
   strb  r1, [r0], #1
-  subs  r2, r2, #1
+  subs  ip, ip, #1
   @ While size is not 0
   bne  L10
   bx   lr
-- 
2.5.0

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

[edk2] [PATCH v2 5/5] BaseTools ARM: add CLANG35 support

[Ard Biesheuvel]

This extends the existing CLANG35 toolchain definition with support for
building for the ARM architecture. In order to be able to reuse the existing
ARM GCC definitions as much as possible, the following changes have been
made to the existing ARM GCC support:
- the -mapcs option has been removed; it is a no-op under Thumb (our default)
  and we use AAPCS (-mabi=aapcs) anyway
- the -mword-relocations option has been moved from GCC_ARM_CC_FLAGS to
  the GCC4x specific option: CLANG does not support it, and uses '-mllvm
  -marm-use-movt=0' instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
Reviewed-by: Liming Gao 
---
 BaseTools/Conf/tools_def.template | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index fc79bd660142..6e26bbca934b 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -366,7 +366,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
Files/CodeSourcery/Sourcery G
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
 #   CLANG35 -Linux,Windows-  Requires:
-# Clang v3.5 or later, and GNU binutils targeting 
aarch64-linux-gnu
+# Clang v3.5 or later, and GNU binutils targeting 
aarch64-linux-gnu or arm-linux-gnueabi
 #Optional:
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
@@ -4322,7 +4322,7 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
-fno-strict-aliasing -
 DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double 
-freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
 DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
-Wno-address -mno-stack-arg-probe
 DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
-minline-int-divide-min-latency
-DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mword-relocations 
-mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char 
-ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb 
-mfloat-abi=soft
+DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-mabi=aapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
 DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -save-temps -fverbose-asm -fsigned-char  -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
-fno-asynchronous-unwind-tables
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
@@ -4380,7 +4380,7 @@ DEFINE GCC46_X64_DLINK_FLAGS = 
DEF(GCC45_X64_DLINK_FLAGS)
 DEFINE GCC46_X64_DLINK2_FLAGS= DEF(GCC45_X64_DLINK2_FLAGS)
 DEFINE GCC46_ASM_FLAGS   = DEF(GCC45_ASM_FLAGS)
 DEFINE GCC46_ARM_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_ASM_FLAGS) -mlittle-endian
-DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector
+DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector 
-mword-relocations
 DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) 
--oformat=elf32-littlearm
 DEFINE GCC46_ARM_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
--defsym=PECOFF_HEADER_SIZE=0x220
 DEFINE GCC46_ARM_ASLDLINK_FLAGS  = DEF(GCC_ARM_ASLDLINK_FLAGS) 
--oformat=elf32-littlearm
@@ -5184,9 +5184,31 @@ RELEASE_GCC49_AARCH64_CC_FLAGS   = 
DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s
 *_CLANG35_*_ASLPP_PATH   = ENV(CLANG35_BIN)clang
 
 DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body
+DEFINE CLANG35_ARM_CC_FLAGS  = DEF(GCC_ARM_CC_FLAGS) -target armv7-a 
-mstrict-align -mllvm -arm-use-movt=0 DEF(CLANG35_WARNING_OVERRIDES)
 DEFINE CLANG35_AARCH64_CC_FLAGS  = DEF(GCC_AARCH64_CC_FLAGS) -target aarch64 
-mcmodel=small -mstrict-align DEF(CLANG35_WARNING_OVERRIDES)
 
 ##
+# CLANG35 ARM definitions
+##
+*_CLANG35_ARM_SLINK_PATH = ENV(CLANG35_ARM_PREFIX)ar
+*_CLANG35_ARM_DLINK_PATH = ENV(CLANG35_ARM_PREFIX)ld
+*_CLANG35_ARM_ASLDLINK_PATH  = ENV(CLANG35_ARM_PREFIX)ld
+*_CLANG35_ARM_RC_PATH= ENV(CLANG35_ARM_PREFIX)objcopy
+
+*_CLANG35_ARM_ASLCC_FLAGS= DEF(GCC_ASLCC_FLAGS)

[edk2] [PATCH v2 4/5] ArmPkg/ArmSoftfloatLib: restrict -fno-tree-vrp option to GCC46

[Ard Biesheuvel]

The -fno-tree-vrp option is not required for GCC 4.7 or later, and is not
supported by CLANG. So restrict its use to GCC 4.6, which is the oldest
version we support for ARM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf 
b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
index 39c74bf1a3c2..b7149d82c3c5 100644
--- a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
+++ b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
@@ -45,5 +45,6 @@ [Packages]
   MdePkg/MdePkg.dec
 
 [BuildOptions]
-  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare -fno-tree-vrp
+  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare
+  *_GCC46_*_CC_FLAGS = -fno-tree-vrp
   RVCT:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC
-- 
2.5.0

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

Re: [edk2] [PATCH v2 4/5] ArmPkg/ArmSoftfloatLib: restrict -fno-tree-vrp option to GCC46

[Leif Lindholm]

On Tue, Dec 15, 2015 at 03:24:55PM +0100, Ard Biesheuvel wrote:
> The -fno-tree-vrp option is not required for GCC 4.7 or later, and is not
> supported by CLANG. So restrict its use to GCC 4.6, which is the oldest
> version we support for ARM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf 
> b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> index 39c74bf1a3c2..b7149d82c3c5 100644
> --- a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> +++ b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> @@ -45,5 +45,6 @@ [Packages]
>MdePkg/MdePkg.dec
>  
>  [BuildOptions]
> -  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare -fno-tree-vrp
> +  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare
> +  *_GCC46_*_CC_FLAGS = -fno-tree-vrp
>RVCT:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC
> -- 
> 2.5.0

I'm still confused about this patch - the reference you included in
your last response pointed to something saying the issue was resolved
in 4.7.1. So would we not need this for GCC46/GCC47?

/
Leif

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

Re: [edk2] [PATCH v2 0/5] add CLANG support for ARM

[Ard Biesheuvel]

On 15 December 2015 at 15:24, Ard Biesheuvel  wrote:
> This series consists of 4 patches that tweak existing ARM code so it can be
> built with Clang, and a final patch against tools_def.template that introduces
> the defines so that '-a ARM' can be combined with '-t CLANG35'
>
> Changes since v1:
> - reshuffled code and added comment to patch #2 (Leif)
> - added R-b's from Leif (#1, #3, #5) and Liming (#5)
>

Committed as SVN r19280 .. r 19284

Thanks everyone

-- 
Ard.


> Ard Biesheuvel (5):
>   ArmPkg: use unified asm syntax for CLANG
>   ArmPkg/CompilerIntrinsicsLib: add GCC version of __aeabi_memset()
>   ArmPkg/ArmV7Lib: add CLANG alternative for FPEXC access
>   ArmPkg/ArmSoftfloatLib: restrict -fno-tree-vrp option to GCC46
>   BaseTools ARM: add CLANG35 support
>
>  ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S  |  9 
> ---
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S|  4 +++
>  ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf|  3 ++-
>  ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S  |  3 ++-
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S | 19 
> +++--
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S   |  5 ++--
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S   |  1 +
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S|  5 ++--
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/switchu8.S   |  5 ++--
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/udivmoddi4.S | 11 
> 
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/udivsi3.S|  3 ++-
>  ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S |  9 
> ---
>  BaseTools/Conf/tools_def.template | 28 
> +---
>  13 files changed, 78 insertions(+), 27 deletions(-)
>
> --
> 2.5.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 0/5] add CLANG support for ARM

[Ard Biesheuvel]

This series consists of 4 patches that tweak existing ARM code so it can be
built with Clang, and a final patch against tools_def.template that introduces
the defines so that '-a ARM' can be combined with '-t CLANG35'

Changes since v1:
- reshuffled code and added comment to patch #2 (Leif)
- added R-b's from Leif (#1, #3, #5) and Liming (#5)

Ard Biesheuvel (5):
  ArmPkg: use unified asm syntax for CLANG
  ArmPkg/CompilerIntrinsicsLib: add GCC version of __aeabi_memset()
  ArmPkg/ArmV7Lib: add CLANG alternative for FPEXC access
  ArmPkg/ArmSoftfloatLib: restrict -fno-tree-vrp option to GCC46
  BaseTools ARM: add CLANG35 support

 ArmPkg/Drivers/CpuDxe/Arm/ExceptionSupport.S  |  9 ---
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S|  4 +++
 ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf|  3 ++-
 ArmPkg/Library/BaseMemoryLibStm/Arm/SetMem.S  |  3 ++-
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S | 19 
+++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch16.S   |  5 ++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch32.S   |  1 +
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switch8.S|  5 ++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/switchu8.S   |  5 ++--
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/udivmoddi4.S | 11 
 ArmPkg/Library/CompilerIntrinsicsLib/Arm/udivsi3.S|  3 ++-
 ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S |  9 ---
 BaseTools/Conf/tools_def.template | 28 
+---
 13 files changed, 78 insertions(+), 27 deletions(-)

-- 
2.5.0

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

Re: [edk2] [PATCH v2 4/5] ArmPkg/ArmSoftfloatLib: restrict -fno-tree-vrp option to GCC46

[Leif Lindholm]

On Tue, Dec 15, 2015 at 03:50:43PM +0100, Ard Biesheuvel wrote:
> On 15 December 2015 at 15:47, Leif Lindholm  wrote:
> > On Tue, Dec 15, 2015 at 03:24:55PM +0100, Ard Biesheuvel wrote:
> >> The -fno-tree-vrp option is not required for GCC 4.7 or later, and is not
> >> supported by CLANG. So restrict its use to GCC 4.6, which is the oldest
> >> version we support for ARM.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf 
> >> b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> >> index 39c74bf1a3c2..b7149d82c3c5 100644
> >> --- a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> >> +++ b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> >> @@ -45,5 +45,6 @@ [Packages]
> >>MdePkg/MdePkg.dec
> >>
> >>  [BuildOptions]
> >> -  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare -fno-tree-vrp
> >> +  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare
> >> +  *_GCC46_*_CC_FLAGS = -fno-tree-vrp
> >>RVCT:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC
> >> --
> >> 2.5.0
> >
> > I'm still confused about this patch - the reference you included in
> > your last response pointed to something saying the issue was resolved
> > in 4.7.1. So would we not need this for GCC46/GCC47?
> >
> 
> Happy to add it for 4.7 as well. I just wonder how many users of GCC
> 4.7 are using 4.7.0. And this is assuming that the -fno-tree-vrp is
> there for a reason that applied to the ARM softfloat code at any point
> in the past.
> 
> So I propose we just make it
> 
> >> -  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare -fno-tree-vrp
> >> +  GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare
> >> +  *_GCC46_*_CC_FLAGS = -fno-tree-vrp
> >> +  *_GCC47_*_CC_FLAGS = -fno-tree-vrp
> 
> and be done with it?

That works for me:
Reviewed-by: Leif Lindholm 

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

Re: [edk2] [Patch 1/2] BootManagerLib: Check the pointer to avoid use NULL pointer.

[Gao, Liming]

Eric:
  Could you check its return status first, then check its return value? 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Dong
Sent: Tuesday, December 15, 2015 9:57 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 1/2] BootManagerLib: Check the pointer to avoid use NULL 
pointer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Library/BootManagerLib/BootManager.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Library/BootManagerLib/BootManager.c 
b/MdeModulePkg/Library/BootManagerLib/BootManager.c
index cfeedeb..dd9838e 100644
--- a/MdeModulePkg/Library/BootManagerLib/BootManager.c
+++ b/MdeModulePkg/Library/BootManagerLib/BootManager.c
@@ -325,10 +325,11 @@ GroupMultipleLegacyBootOption4SameType (
   EFI_BOOT_MANAGER_LOAD_OPTION BootOption;
 
   SetMem (DeviceTypeIndex, sizeof (DeviceTypeIndex), 0xff);
 
   GetEfiGlobalVariable2 (L"BootOrder", (VOID **) , );
+  ASSERT (BootOrder != NULL);
 
   for (Index = 0; Index < BootOrderSize / sizeof (UINT16); Index++) {
 UnicodeSPrint (OptionName, sizeof (OptionName), L"Boot%04x", 
BootOrder[Index]);
 Status = EfiBootManagerVariableToLoadOption (OptionName, );
 ASSERT_EFI_ERROR (Status);
-- 
1.9.5.msysgit.1

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

Re: [edk2] [Patch] MdeModulePkg: Change file format which the existed folder has mixed file format

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Dong, Eric 
Sent: Wednesday, December 16, 2015 8:55 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [edk2] [Patch] MdeModulePkg: Change file format which the existed 
folder has mixed file format

Convert the file format from Unix format to DOS for the folder which has mixed 
file format. 

The git codebase in my local already convert to the dos format auto, so I send 
a svn format patch instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 

Index: Include/Library/FileExplorerLib.h
===
--- Include/Library/FileExplorerLib.h   (revision 19246)
+++ Include/Library/FileExplorerLib.h   (working copy)
@@ -1,60 +1,60 @@
-/** @file
-
-  This library class defines a set of interfaces for how to do file explorer.
-
-Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
-This program and the accompanying materials are licensed and made available 
under 
-the terms and conditions of the BSD License that accompanies this 
distribution.  
-The full text of the license may be found at
-http://opensource.org/licenses/bsd-license.php.

-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#ifndef __FILE_EXPLORER_LIB_H__
-#define __FILE_EXPLORER_LIB_H__
-
-/**
-  Prototype for the next process after user chosed one file.
-
-  @param[in] FilePath The device path of the find file.
-
-  @retvalTRUE Need exit file explorer after do the extra task.
-  @retvalFALSENot need to exit file explorer after do the extra 
task.
-
-**/
-typedef
-BOOLEAN
-(EFIAPI *CHOOSE_HANDLER)(
-  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
-  );
-
-/**
-  Choose a file in the specified directory. 
-
-  If user input NULL for the RootDirectory, will choose file in the system.
-
-  If user input *File != NULL, function will return the allocate device path
-  info for the choosed file, caller has to free the memory after use it.
-
-  @param  RootDirectoryPointer to the root directory.
-  @param  FileType The file type need to choose.
-  @param  ChooseHandlerFunction pointer to the extra task need to do
-   after choose one file.
-  @param  File Return the device path for the last time chosed 
file.
-
-  @retval EFI_SUCESS   Choose the file success.
-  @retval Other errors Choose the file failed.
-**/
-EFI_STATUS
-EFIAPI
-ChooseFile (
-  IN  EFI_DEVICE_PATH_PROTOCOL  *RootDirectory,
-  IN  CHAR16*FileType,  OPTIONAL
-  IN  CHOOSE_HANDLERChooseHandler,  OPTIONAL
-  OUT EFI_DEVICE_PATH_PROTOCOL  **File  OPTIONAL
-  );
-
-#endif
+/** @file
+
+  This library class defines a set of interfaces for how to do file explorer.
+
+Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under 
+the terms and conditions of the BSD License that accompanies this 
distribution.  
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.

+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __FILE_EXPLORER_LIB_H__
+#define __FILE_EXPLORER_LIB_H__
+
+/**
+  Prototype for the next process after user chosed one file.
+
+  @param[in] FilePath The device path of the find file.
+
+  @retvalTRUE Need exit file explorer after do the extra task.
+  @retvalFALSENot need to exit file explorer after do the extra 
task.
+
+**/
+typedef
+BOOLEAN
+(EFIAPI *CHOOSE_HANDLER)(
+  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
+  );
+
+/**
+  Choose a file in the specified directory. 
+
+  If user input NULL for the RootDirectory, will choose file in the system.
+
+  If user input *File != NULL, function will return the allocate device path
+  info for the choosed file, caller has to free the memory after use it.
+
+  @param  RootDirectoryPointer to the root directory.
+  @param  FileType The file type need to choose.
+  @param  ChooseHandlerFunction pointer to the extra task need to do
+   after choose one file.
+  @param  File Return the device path for the last time chosed 
file.
+
+  @retval EFI_SUCESS   Choose the file success.
+  @retval Other errors Choose the file failed.
+**/
+EFI_STATUS
+EFIAPI
+ChooseFile (
+  IN  EFI_DEVICE_PATH_PROTOCOL  *RootDirectory,
+  IN  CHAR16*FileType,  OPTIONAL
+  IN  CHOOSE_HANDLERChooseHandler,  OPTIONAL
+  OUT EFI_DEVICE_PATH_PROTOCOL 

[edk2] [patch] MdeModulePkg:Fix a bug HttpLib can't parse last chunked data well

[Zhang Lubo]

When HttpLib parsing the last chunked data down, the Http NextMsg pointer
in the HttpBodyParserCallback function should point to the character
after '/n' flag.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 39 +---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c 
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index 49fa80b..143baab 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -1159,25 +1159,11 @@ HttpParseMessageBody (
   for (Char = Body; Char < Body + BodyLength; ) {
 
 switch (Parser->State) {
 case BodyParserStateMax:
   return EFI_ABORTED;
-
-case BodyParserComplete:
-  if (Parser->Callback != NULL) {
-Status = Parser->Callback (
-   BodyParseEventOnComplete,
-   Char,
-   0,
-   Parser->Context
-   );
-if (EFI_ERROR (Status)) {
-  return Status;
-}
-  }
-  return EFI_SUCCESS;
-
+ 
 case BodyParserBodyIdentity:
   //
   // Identity transfer-coding, just notify user to save the body data.
   //
   if (Parser->Callback != NULL) {
@@ -1193,10 +1179,21 @@ HttpParseMessageBody (
   }
   Char += MIN (BodyLength, Parser->ContentLength - 
Parser->ParsedBodyLength);
   Parser->ParsedBodyLength += MIN (BodyLength, Parser->ContentLength - 
Parser->ParsedBodyLength);
   if (Parser->ParsedBodyLength == Parser->ContentLength) {
 Parser->State = BodyParserComplete;
+if (Parser->Callback != NULL) {
+  Status = Parser->Callback (
+ BodyParseEventOnComplete,
+ Char,
+ 0,
+ Parser->Context
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+}
   }
   break;
 
 case BodyParserChunkSizeStart:
   //
@@ -1270,10 +1267,22 @@ HttpParseMessageBody (
   }
   
 case BodyParserLastCRLFEnd:
   if (*Char == '\n') {
 Parser->State = BodyParserComplete;
+Char++;
+if (Parser->Callback != NULL) {
+  Status = Parser->Callback (
+ BodyParseEventOnComplete,
+ Char,
+ 0,
+ Parser->Context
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+}
 break;
   } else {
 Parser->State = BodyParserStateMax;
 break;
   }
-- 
1.9.5.msysgit.1

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

[edk2] recommended ARM toolchain

[Michael Zimmermann]

Hi,

when reading building guides etc u always find people using
"arm-linux-gnueabihf-" for building UEFI.
But does that actually make sense? I'd rather use sth. like Google's kernel
toolchain "arm-eabi-".

UEFI doesn't actually use standard libs so the eabi shouldn't matter.
Also I don't think using hardfloat is a good idea in bootloaders either.

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