On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin olivier.martin@arm.com wrote:
$
/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, r00000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:
b4f0: 000b0000 andeq r0, fp, r0I 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!
Thanks Olivier! The '.dll' dump looks similar to ^ and contains proper PCD values at the right address. The '.lib' however shows all the PCDs to be at 00000000:
Disassembly of section .rodata._gPcd_FixedAtBuild_PcdFvBaseAddress:
00000000 <_gPcd_FixedAtBuild_PcdFvBaseAddress>: 0: 80008000 andhi r8, r0, r0
Is it all right that these two addresses are different? If so, what else sould I check to trace the fault?
Thanks, Varad
On Jul 29, 2014, at 5:32 AM, Varad Gautam varadgautam@gmail.com wrote:
On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin olivier.martin@arm.com wrote:
$ /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, r00000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:
b4f0: 000b0000 andeq r0, fp, r0I 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!
Thanks Olivier! The '.dll' dump looks similar to ^ and contains proper PCD values at the right address. The '.lib' however shows all the PCDs to be at 00000000:
Disassembly of section .rodata._gPcd_FixedAtBuild_PcdFvBaseAddress:
00000000 <_gPcd_FixedAtBuild_PcdFvBaseAddress>: 0: 80008000 andhi r8, r0, r0
Is it all right that these two addresses are different?
Yes if the global was an extern then the library (set of object files) would contain an object relocation entry to let the linker know what filial value ends up at this address.
Note: The object relocations are not the same set as the image relocations that the EFI code supports in the PE/COFF libraries. The image relocations only have to fixup addresses, but object relocations also need to resolve external references.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/BasePeCoffLib/
Thanks,
Andrew Fish
If so, what else sould I check to trace the fault?
Thanks, Varad
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl... edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Issue fixed. I am using MLO to load the Fd, which loads u-boot.img at CONFIG_SYS_TEXT_BASE=0x80800000 [1]. PcdFdBaseAddress needed to be set to the same address.
[1] https://gitorious.org/rowboat/u-boot/source/562aa886438ea60cda487565b548b714...
Thanks, Varad
On Tue, Jul 29, 2014 at 9:05 PM, Andrew Fish afish@apple.com wrote:
On Jul 29, 2014, at 5:32 AM, Varad Gautam varadgautam@gmail.com wrote:
On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin olivier.martin@arm.com wrote:
$
/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, r00000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:
b4f0: 000b0000 andeq r0, fp, r0I 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!
Thanks Olivier! The '.dll' dump looks similar to ^ and contains proper PCD values at the right address. The '.lib' however shows all the PCDs to be at 00000000:
Disassembly of section .rodata._gPcd_FixedAtBuild_PcdFvBaseAddress:
00000000 <_gPcd_FixedAtBuild_PcdFvBaseAddress>: 0: 80008000 andhi r8, r0, r0
Is it all right that these two addresses are different?
Yes if the global was an extern then the library (set of object files) would contain an object relocation entry to let the linker know what filial value ends up at this address.
Note: The object relocations are not the same set as the image relocations that the EFI code supports in the PE/COFF libraries. The image relocations only have to fixup addresses, but object relocations also need to resolve external references.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/BasePeCoffLib/
Thanks,
Andrew Fish
If so, what else sould I check to trace the fault?
Thanks, Varad
Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.cl...
edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-uefi
-
Andrew Fish -
Varad Gautam