On Jul 23, 2014, at 5:36 AM, Laszlo Ersek lersek@redhat.com wrote:

On 07/23/14 13:34, Varad Gautam wrote:

...

Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an issue with PcdGet(): it always returns `0` no matter what the PCD is set to. However, FixedPcdGet() works fine (I've had to patch edk2 to replace all PcdGet calls with FixedPcdGet to get PrePi working which is a bad idea).

What form do get for _PCD_GET_MODE_*_PcdFvBaseAddress in the AutoGen.h? That is the real issue.

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/PcdLib... #define PcdGet8(TokenName) _PCD_GET_MODE_8_##TokenName The behavior of libraries (try to inherit things from drivers) and drivers is different. Where is the PCD in question?

...

The build report too shows the PCDs being set to their proper values, and so do the AutoGen.i file macros like `const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress = 0x80008000U;`

I've come up with two reasons to this,

• Is there a build flag I'm missing to enable PcdGet support?
• `_gPcd_FixedAtBuild_PcdFvBaseAddress` is declared with

`GLOBAL_REMOVE_IF_UNREFERENCED` in AutoGen.c and gets removed before I can use it. This also explains why FixedPcdGet would work, since `_PCD_VALUE_PcdFvBaseAddress` is correctly #defined to be 0x80008000U.

This happens for all fixed-at-build type PCDs. Also, I'm linked to PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf for the buid. What could I try to fix it?

You're getting this result because you're combining incorrect library class resolution with RELEASE builds.

Yes it is good to debug with DEBUG builds.

Thanks,

Andrew Fish

(I cannot condemn RELEASE builds enough.) Namely, you call

UINT32 EFIAPI LibPcdGet32 ( IN UINTN TokenNumber ) { ASSERT (FALSE);

 return 0;

}

from "MdePkg/Library/BasePcdLibNull/PcdLib.c", and since you build for RELEASE, the ASSERT() is a no-op. In a DEBUG build you'd have caught this immediately with a failed assertion: the Null implementation of PcdLib doesn't allow you to actually access PCDs.

Library instances that usably resolve the PcdLib library class are:

$ git grep -l 'LIBRARY_CLASS *= *PcdLib' -- '*.inf'

EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf MdePkg/Library/DxePcdLib/DxePcdLib.inf MdePkg/Library/PeiPcdLib/PeiPcdLib.inf

In PEIMs, you need the fourth; in DXE & UEFI drivers, you need the third.

However, this is not the entire picture yet, because these libraries delegate the work to a PPI (in PEI) and to a protocol (in DXE) that are provided by dedicated drivers, respectively:

• MdeModulePkg/Universal/PCD/Pei/Pcd.inf
• MdeModulePkg/Universal/PCD/Dxe/Pcd.inf

You should add these drivers to the corresponding (ie. PEI vs. DXE) APRIORI files of the firmware volumes that your FDF file defines, so that any driver loaded / dispatched later can use their PCD services (through the above-mentioned library instances). Refer to OvmfPkg/OvmfPkgX64.fdf for examples.

Thanks Laszlo

---

Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel

On Jul 23, 2014, at 9:56 AM, Varad Gautam varadgautam@gmail.com wrote:

On Wed, Jul 23, 2014 at 9:43 PM, Andrew Fish afish@apple.com wrote:

...

What form do get for _PCD_GET_MODE_*_PcdFvBaseAddress in the AutoGen.h? That is the real issue.

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/PcdLib...

#define PcdGet8(TokenName) _PCD_GET_MODE_8_##TokenName

The behavior of libraries (try to inherit things from drivers) and drivers is different. Where is the PCD in question?

I see that `PeiUniCore/DEBUG/AutoGen.h` contains `#define _PCD_GET_MODE_32_PcdFvBaseAddress _gPcd_FixedAtBuild_PcdFvBaseAddress`

and `PeiUniCore/DEBUG/AutoGen.c`: `GLOBAL_REMOVE_IF_UNREFERENCED const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress = _PCD_VALUE_PcdFvBaseAddress;`

also, in PeiUniCore/DEBUG/AutoGen.h `#define _PCD_VALUE_PcdFvBaseAddress 0x80008000U`

So _PCD_GET_MODE_32_PcdFvBaseAddress should get set to the right value.

On Jul 23, 2014, at 5:36 AM, Laszlo Ersek lersek@redhat.com wrote:

...

(I cannot condemn RELEASE builds enough.) Namely, you call

UINT32 EFIAPI LibPcdGet32 ( IN UINTN TokenNumber ) { ASSERT (FALSE);

 return 0;

}

from "MdePkg/Library/BasePcdLibNull/PcdLib.c", and since you build for RELEASE, the ASSERT() is a no-op. In a DEBUG build you'd have caught this immediately with a failed assertion: the Null implementation of PcdLib doesn't allow you to actually access PCDs.

Oddly, the call to PcdGet32() from PrePi doesn't get here. It takes the MdePkg/Include/Library/PcdLib.h: #define PcdGet32(TokenName) _PCD_GET_MODE_32_##TokenName route instead.

What is the AutoGen.* for the library?

Thanks,

Andrew Fish

...

Library instances that usably resolve the PcdLib library class are:

$ git grep -l 'LIBRARY_CLASS *= *PcdLib' -- '*.inf'

EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf MdePkg/Library/DxePcdLib/DxePcdLib.inf MdePkg/Library/PeiPcdLib/PeiPcdLib.inf

In PEIMs, you need the fourth; in DXE & UEFI drivers, you need the third.

However, this is not the entire picture yet, because these libraries delegate the work to a PPI (in PEI) and to a protocol (in DXE) that are provided by dedicated drivers, respectively:

• MdeModulePkg/Universal/PCD/Pei/Pcd.inf
• MdeModulePkg/Universal/PCD/Dxe/Pcd.inf

You should add these drivers to the corresponding (ie. PEI vs. DXE) APRIORI files of the firmware volumes that your FDF file defines, so that any driver loaded / dispatched later can use their PCD services (through the above-mentioned library instances). Refer to OvmfPkg/OvmfPkgX64.fdf for examples.

Thanks, I was unaware of that.

Varad

Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel

On Jul 23, 2014, at 10:58 AM, Varad Gautam varadgautam@gmail.com wrote:

What is the AutoGen.* for the library?

Thanks,

Andrew Fish

Do you mean the platform library? Library/Am335xLib/AutoGen.h shows

#define _PCD_TOKEN_PcdFvBaseAddress 8U extern const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress; #define _PCD_GET_MODE_32_PcdFvBaseAddress _gPcd_FixedAtBuild_PcdFvBaseAddress //#define _PCD_SET_MODE_32_PcdFvBaseAddress ASSERT(FALSE) // It is not allowed to set value for a FIXED_AT_BUILD PCD #define _PCD_VALUE_PcdFvBaseAddress 0x80008000

If you mean the BasePcdLibNull's AutoGen.h, it does not define any PCDs (since the .inf does not mention any PCDs)

The code is calling LibPcdGet32() for the FixedAtBuild PCD?

Thanks,

Andrew Fish

Thanks, Varad

---

Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel

On Jul 23, 2014, at 11:44 AM, Varad Gautam varadgautam@gmail.com wrote:

On Wed, Jul 23, 2014 at 11:39 PM, Andrew Fish afish@apple.com wrote:

...

The code is calling LibPcdGet32() for the FixedAtBuild PCD?

The execution never comes to calling LibPcdGet32(), for either BasePcdLibNull or PcdLib.

Sorry so I’m confused. What is the issue you are seeing? Why is PcdGet32() returning 0 and not the fixed PCD value?

Thanks,

Andrew Fish

Thanks, Varad

---

Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel

On Jul 23, 2014, at 12:07 PM, Varad Gautam varadgautam@gmail.com wrote:

On Thu, Jul 24, 2014 at 12:20 AM, Andrew Fish afish@apple.com wrote:

...

Sorry so I’m confused. What is the issue you are seeing? Why is PcdGet32() returning 0 and not the fixed PCD value?

Thanks,

Andrew Fish

The problem is that even though the PCDs are set to right value in the AutoGen.h files and in the Build Report, PcdGet always returns 0 whereas FixedPcdGet works.

Is it the same in the global area and under the driver?

What is the value for _PCD_GET_MODE_32_##TokenName in the autogen of the module where the 0 is returned? Is it calling LibPcdGet32() or does it point to the global?

#define PcdGet32(TokenName) _PCD_GET_MODE_32_##TokenName

It could be due to what Laszlo suggested earlier, but I already am building for DEBUG. ASSERT() acts as a no-op for me because PcdGet at [1] simply returns 0 and DebugAssertEnabled always fails!

I don’t understand how that statement matches this statement you made: “The execution never comes to calling LibPcdGet32(), for either BasePcdLibNull or PcdLib.”

[1] https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseDebugLibSer...

Thanks, Varad

On Jul 24, 2014, at 6:56 AM, Varad Gautam varadgautam@gmail.com wrote:

On Thu, Jul 24, 2014 at 12:51 AM, Andrew Fish afish@apple.com wrote:

...

What is the value for _PCD_GET_MODE_32_##TokenName in the autogen of the module where the 0 is returned? Is it calling LibPcdGet32() or does it point to the global?

_PCD_GET_MODE_32_##TokenName is #defined to the appropriate _gPcd_FixedAtBuild_##TokenName in AutoGen.h of my module. LibPcdGet32() is not called. The same module's AutoGen.i contains const UINT32 _gPcd_FixedAtBuild_##TokenName = <right_pcd_value>;

But when I check the value of _gPcd_FixedAtBuild_##TokenName from my module, it always shows as 0.

AutoGen.i? Is this code assembly? If so you should look at the *.iii as that is the post processed version that gets sent to assembler. There is a tool to trim out code that is not compatible with the assembler, so it would be good to check that something is not going on in that step.

Are the globals in the image? What value do they have? You should be able to dump PE/COFF or ELF on your build system and find out.

...

#define PcdGet32(TokenName) _PCD_GET_MODE_32_##TokenName

It could be due to what Laszlo suggested earlier, but I already am building for DEBUG. ASSERT() acts as a no-op for me because PcdGet at [1] simply returns 0 and DebugAssertEnabled always fails!

I don’t understand how that statement matches this statement you made: “The execution never comes to calling LibPcdGet32(), for either BasePcdLibNull or PcdLib.”

I meant that ASSERT() statements do nothing throughout the codebase because of PcdGet failing.

OK that makes sense. If you dump the build.log for your module you can double check that you are only using FixedAtBuid PCDs. The 1st list of PCDs is the global list, but the each module has its list too and that is the one you want to look at.

On Wed, Jul 23, 2014 at 6:06 PM, Laszlo Ersek lersek@redhat.com wrote:

...

Library instances that usably resolve the PcdLib library class are:

$ git grep -l 'LIBRARY_CLASS *= *PcdLib' -- '*.inf'

EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf MdePkg/Library/DxePcdLib/DxePcdLib.inf MdePkg/Library/PeiPcdLib/PeiPcdLib.inf

In PEIMs, you need the fourth; in DXE & UEFI drivers, you need the third.

I think I might not need these implementations for the PEI phase since I am not using any Dymanic PCDs (as suggested in sec. 4.102 - "MdePkg Document With Libraries.pdf" at [1]).

...

However, this is not the entire picture yet, because these libraries delegate the work to a PPI (in PEI) and to a protocol (in DXE) that are provided by dedicated drivers, respectively:

• MdeModulePkg/Universal/PCD/Pei/Pcd.inf
• MdeModulePkg/Universal/PCD/Dxe/Pcd.inf

You should add these drivers to the corresponding (ie. PEI vs. DXE) APRIORI files of the firmware volumes that your FDF file defines, so that any driver loaded / dispatched later can use their PCD services (through the above-mentioned library instances). Refer to OvmfPkg/OvmfPkgX64.fdf for examples.

How are APRIORI drivers initialized? I couldn't figure which phase is responsible for launching them.

The PEI and DXE dispatcher pre load their dispatch queues with the contents of the APRIORI file. The APRIORI file is discovered as the PEI/DXE dispatcher walks the firmware volume to find the modules to dispatch.

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Dispatc... // // Read the array of GUIDs from the Apriori file if it is present in the firmware volume // AprioriFile = NULL; Status = Fv->ReadSection ( Fv, &gAprioriGuid, EFI_SECTION_RAW, 0, (VOID **)&AprioriFile, &SizeOfBuffer, &AuthenticationStatus ); if (!EFI_ERROR (Status)) { AprioriEntryCount = SizeOfBuffer / sizeof (EFI_GUID); } else { AprioriEntryCount = 0; }

// // Put drivers on Apriori List on the Scheduled queue. The Discovered List includes // drivers not in the current FV and these must be skipped since the a priori list // is only valid for the FV that it resided in. //

for (Index = 0; Index < AprioriEntryCount; Index++) { for (Link = mDiscoveredList.ForwardLink; Link != &mDiscoveredList; Link = Link->ForwardLink) { DriverEntry = CR(Link, EFI_CORE_DRIVER_ENTRY, Link, EFI_CORE_DRIVER_ENTRY_SIGNATURE); if (CompareGuid (&DriverEntry->FileName, &AprioriFile[Index]) && (FvHandle == DriverEntry->FvHandle)) { CoreAcquireDispatcherLock (); DriverEntry->Dependent = FALSE; DriverEntry->Scheduled = TRUE; InsertTailList (&mScheduledQueue, &DriverEntry->ScheduledLink); CoreReleaseDispatcherLock (); DEBUG ((DEBUG_DISPATCH, "Evaluate DXE DEPEX for FFS(%g)\n", &DriverEntry->FileName)); DEBUG ((DEBUG_DISPATCH, " RESULT = TRUE (Apriori)\n")); break; } } } All the APRIORI file does is cause the PEI/DXE dispatcher to skip dependency (Depex) processing to decide driver order.

It does not really help with PCD. The Library that uses the PPI has a dependency on the PPI, and when you link this library against your PEIM your PEIM inherits the dependency. If you link against the NULL version of the lib you don’t get the dependency.

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/PeiPcdLib/PeiP... [Depex.common.PEIM] gEfiPeiPcdPpiGuid

The only feature that the APRIORI file adds, that is not possible with the dependency expressions, is ordering modules with the same depex. Basically the PI spec states if you have 10 driver that have a depex that is TRUE the order those drivers run is not defined by the architecture. If the depex are all TRUE it is safe to run any of the drivers. Maybe one of the drivers is a debugger stub and you want to force that one to be 1st, this is what the APRIORI list is for.

Thanks,

Andrew Fish

[1] http://sourceforge.net/projects/edk2/files/EDK_II_Libraries/UDK2014/

Thanks, Varad

---

Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel

On Thu, Jul 24, 2014 at 9:50 PM, Andrew Fish afish@apple.com wrote:

AutoGen.i? Is this code assembly? If so you should look at the *.iii as that is the post processed version that gets sent to assembler. There is a tool to trim out code that is not compatible with the assembler, so it would be good to check that something is not going on in that step.

Yeah, AutoGen.i contains assembly. The .iii files too point to the global.

Are the globals in the image? What value do they have? You should be able to dump PE/COFF or ELF on your build system and find out.

This is interesting, the objdump contains 0 for PcdGet at all places.

On Thu, Jul 24, 2014 at 10:06 PM, Laszlo Ersek lersek@redhat.com wrote:

(Maybe side issue, maybe relevant:)

Interesting. I tried to use fixed PCDs in ASL source code, *after* BaseTools had reportedly grown support for that. Unfortunately, my attempt failed, and I got no effective advice after I reported it.

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7416/focus=7587

Perhaps this is a basetools problem then?

Thanks Laszlo

The AutoGen.h contains the correct PCD values, so basetools is able to parse and append PCDs properly. I'll try to dig deeper into it.

Does `PcdPeiGlobalVariableSize` play any role during build?

Thanks, Varad

On Jul 25, 2014, at 4:07 AM, Varad Gautam varadgautam@gmail.com wrote:

The same problem appears when I build BeagleBoardPkg: AutoGen.* contains proper PCDs, so does the build report. Yet, objdump shows PcdGet calls to return 0. -objdump snippets- ArmPlatformPrePiUnicore.lib: FixedPcdGet32 (PcdFdBaseAddress); 5e: f04f 2080 mov.w r0, #2147516416 ; 0x80008000 62: f7ff fffe bl 0 <PrePiMain> ... StacksSize = PcdGet32 (PcdCPUCorePrimaryStackSize); bc: 4b6e ldr r3, [pc, #440] ; (278 <PrePiMain+0x278>) be: 681b ldr r3, [r3, #0] c0: 9325 str r3, [sp, #148] ; 0x94

This looks like a GOT load. The address pc+440 is the address of the pointer to the global. What does pc+440 point to?

Maybe your toolchain is having an issue with GOT?

Thanks,

Andrew Fish

PS If you reference a global you were not compiled with, but linked with it becomes an indirect access. this is clang, but you get the idea (I used armv6 as armv7 emits movw/movt). The linker would patch L_global$non_lazy_ptr with a pointer to the global at link time.

~/work/Compiler>cat got.c

extern int global;

int test() { return global; }

~/work/Compiler>clang -arch armv6 -Os -S got.c ~/work/Compiler>cat got.S .section __TEXT,__text,regular,pure_instructions .section __TEXT,__textcoal_nt,coalesced,pure_instructions .section __TEXT,__const_coal,coalesced .section __TEXT,__picsymbolstub4,symbol_stubs,none,16 .section __TEXT,__StaticInit,regular,pure_instructions .section __TEXT,__cstring,cstring_literals .syntax unified .section __TEXT,__text,regular,pure_instructions .globl _test .align 2 _test: @ @test @ BB#0: ldr r0, LCPI0_0 LPC0_0: ldr r0, [pc, r0] ldr r0, [r0] bx lr .align 2 @ BB#1: .data_region LCPI0_0: .long L_global$non_lazy_ptr-(LPC0_0+8) .end_data_region

.section __DATA,__nl_symbol_ptr,non_lazy_symbol_pointers .align 2 L_global$non_lazy_ptr: .indirect_symbol _global .long 0

.subsections_via_symbols

I have tried using a different toolchain :). What else is possible? I am looking into the BaseTools build process. Could someone please verify this for BeagleBoardPkg?

Thanks, Varad

On Fri, Jul 25, 2014 at 10:06 PM, Olivier Martin Olivier.Martin@arm.com wrote:

Which toolchain are you using? Could I have a link to it?

Thanks,

Olivier

I've tried the GNU gcc-arm-none- 4.6 and 4.8 toolchains at [1] and Linaro 4.8 [2].

[1] https://launchpad.net/gcc-arm-embedded [2] https://launchpad.net/gcc-arm-embedded/+milestone/4.8-2014-q2-update

Thanks, Varad

On Sat, Jul 26, 2014 at 12:04 AM, Olivier Martin Olivier.Martin@arm.com wrote:

Try this one: http://releases.linaro.org/14.04/components/toolchain/gcc-linaro/4.8/gcc-lin... with the EDK2 Toolchain 'GCC48'.

Didn't work either, tried building from source as well as the pre-built binaries at [1].

Checking GOT now.

[1] http://releases.linaro.org/14.04/components/toolchain/binaries

Thanks, Varad

I have just looked at the BeagleBoard and the result seems correct:

$ build -a ARM -p BeagleBoardPkg/BeagleBoardPkg.dsc -t GCC48

$ /work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump -S -D Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll

FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdBaseAddress) + (EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdSize);

705c: 4b90 ldr r3, [pc, #576] ; (72a0 <MemoryPeim+0x2a4>)

705e: 681b ldr r3, [r3, #0]

7060: 4618 mov r0, r3

7062: f04f 0100 mov.w r1, #0

7066: 4b8f ldr r3, [pc, #572] ; (72a4 <MemoryPeim+0x2a8>)

7068: 681b ldr r3, [r3, #0]

706a: 461a mov r2, r3

706c: f04f 0300 mov.w r3, #0

(...)

72a0: 0000b4ec andeq fp, r0, ip, ror #9

72a4: 0000b4f0 strdeq fp, [r0], -r0

(...)

0000b4ec <_gPcd_FixedAtBuild_PcdFdBaseAddress>:

b4ec: 80008000 andhi r8, r0, r0

0000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:

b4f0: 000b0000 andeq r0, fp, r0

I noticed in an earlier email you mentioned ArmPlatformPrePiUniCore.lib. If you want to look at the final ELF file, you should have a look at ‘.dll’. I know the name is confusing... But ‘.dll’ is actually a ELF file!

From: Varad Gautam [mailto:varadgautam@gmail.com] Sent: 29 July 2014 08:56 To: Olivier Martin Cc: edk2-devel@lists.sourceforge.net; linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] [edk2] Strange Issue With PcdGetXX()

The PCDs I'm using for BBB show listed under 'Discarded input sections' in ArmPlatformPrePiUniCore.map, wheareas when building OvmfPkgX64, PCDs are not discarded.

So I am thinking,

* Does this mean they are not being referenced properly? I'll checkout how OvmfPkg

is using them.

* Is 'GLOBAL_REMOVE_IF_UNREFERENCED' in AutoGen.h responsible for this? [1]

[1] https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg07501.html

Thanks, Varad

On Sat, Jul 26, 2014 at 11:14 PM, Varad Gautam varadgautam@gmail.com wrote:

On Sat, Jul 26, 2014 at 12:04 AM, Olivier Martin Olivier.Martin@arm.com wrote:

Try this one: http://releases.linaro.org/14.04/components/toolchain/gcc-linaro/4.8/gcc-lin... with the EDK2 Toolchain 'GCC48'.

Didn't work either, tried building from source as well as the pre-built binaries at [1].

Checking GOT now.

[1] http://releases.linaro.org/14.04/components/toolchain/binaries

Thanks, Varad