Hi Andrew,
I am using Trace32 for debugging. I need COFF file for debugging. Is there
any single final COFF file for debugging?
On Wed, Nov 28, 2012 at 9:09 PM, Andrew Fish <af...@apple.com> wrote:
> James,
>
> This could have to do with you looking at the object file that has NOT
> been linked, the things that are zero probably need to get resolved by the
> linker.
>
> You want to look at the linked output and that should be in the
> Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/DEBUG
> directory. Try the *.efi, this should work if you objdump supports
> PE/COFF. If this does not work then look at the *.dll file. You should
> also be able to look at the map file, *.map, to get info about the link.
>
> Andrew Fish
>
>
> On Nov 28, 2012, at 2:45 AM, James White wrote:
>
> Thanks for your help.
>
> When I look at just the first few lines of the disassembled code of
> SecEntryPoint.S then I get the following output:
>
> arm-linux-gnueabi-objdump -d
> Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/OUTPUT/SecEntryPoint.obj
>
>
> Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/OUTPUT/SecEntryPoint.obj:
> file format elf32-littlearm
>
> Disassembly of section .text:
>
> 00000000 <StartupAddr>:
> 0: 00000000 .word 0x00000000
>
> 00000004 <_ModuleEntryPoint>:
> 4: ebfffffe bl 0 <ArmDisableInterrupts>
> 8: ebfffffe bl 0 <ArmDisableCachesAndMmu>
> c: e3a0a001 mov sl, #1
> 10: fafffffe blx 0 <ArmPlatformSecBootAction>
>
> 00000014 <_IdentifyCpu>:
> 14: ebfffffe bl 0 <ArmReadMpidr>
> 18: e59f10a4 ldr r1, [pc, #164] ; c4 <_NeverReturn+0x4>
> 1c: e0005001 and r5, r0, r1
> 20: e3a03000 mov r3, #0
> 24: e1550003 cmp r5, r3
> 28: 0a000003 beq 3c <_InitMem>
>
> I am a bit surprised that it seem that all functions outside of Sec are
> set to "0", e.g. ArmDisableInterrupts etc. Or do I not read it properly?
> When are the addresses of those functions defined? Does that part come
> later when linking all of them together as single binary?
>
>
> Yes
>
> Thanks for any pointers.
>
> ------------------------------
> From: af...@apple.com
> Date: Tue, 27 Nov 2012 11:25:22 -0800
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Disassemble UEFI FV
>
>
> On Nov 27, 2012, at 9:21 AM, James White wrote:
>
> Hi Andrew
>
> Thanks for your reply. Great help.
>
> I currently have the problem that I'm trying to split SEC from
> PEI/DXE/BDS. I load the Sec module into a read-only ROM. The ROM is
> memory-mapped at 0x0 (this is specific to my platform).
> When I disassemble Sec/Sec/OUTPUT/SecEntryPoint.obj I can see that the
> address of CEntryPoint/StartupAddr is 0x0.
>
> 00000000 <StartupAddr>:
> 0: 00000000 .word 0x00000000
>
> This is the entry point for Sec.c (not the startup function of
> SecEntryPoint.S) but doesn't that conflict with me having the ROM mapped at
> 0x0?
> I cannot get any output of my system because it fails so early at power
> on. I'm currently using ARM's Fast Model simulation to find the problem.
>
>
> You can look at the link map for Sec and see the linked address of the
> symbols. It is likely that the Sec will be linked at 0x00000000 or
> 0x00000240 (started with non-PE/COFF image). The info in the FDF file is
> used to relocate Sec to its execute in place address. So In my example that
> would shift everything over by 0xEC000000 + offset of the Sec PE/COFF image
> in the FD.
>
> Just to clarify, what exactly does the BaseAddress mean? Is that where the
> flash device is memory-mapped on the system, or just some location in RAM
> where we can relocate code to?
>
>
> This is the address the FD will execute from. So on a PC this a FLASH ROM
> address. On a BeagleBoard the mask ROM turns on DRAM and reads a table from
> ROM and shadows the FD into RAM, so it is a RAM address.
>
> Thanks again for your help.
>
>
> ------------------------------
> From: af...@apple.com
> Date: Tue, 27 Nov 2012 08:44:13 -0800
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Disassemble UEFI FV
>
> The edk2 build system produces a command line tool called VolInfo that
> dumps FVs. It does not disassemble code, but it will show you the layout.
>
> The FD layout is defined in the platforms .FDF file. Look in the [FD.*]
> sections. So for example:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/ArmPlatformPkg.fdf
>
> [FD.Sec_ArmPlatform_EFI]
> BaseAddress = 0xEC000000|gArmTokenSpaceGuid.PcdSecureFdBaseAddress #The
> base address of the Secure FLASH Device.
> Size = 0x00010000|gArmTokenSpaceGuid.PcdSecureFdSize #The
> size in bytes of the Secure FLASH Device
> ErasePolarity = 1
> BlockSize = 0x00001000
> NumBlocks = 0x10
>
> 0x00000000|0x00010000
> gArmTokenSpaceGuid.PcdSecureFvBaseAddress|gArmTokenSpaceGuid.PcdSecureFvSize
> FV = FVMAIN_SEC
>
> So FVMAIN_SEC is relocated to 0xEC000000. This relocation is done when the
> build calls GenFv. The FV header starts with a zero vector (16-bytes of
> zero), on ARM these values are patched with a branch to the entry point of
> the SEC Core. See UpdateArmResetVectorIfNeeded() in
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c
> .
>
> The FV layout is completely defined in the UEFI Platform Initialization
> (PI) Specification 1.2.1 @ http://www.uefi.org/specs/
>
> Disassembly is usually done via a JTAG debugger (I assume you don't have
> one) or by using a debugger. So if you have gdb you can use the VolInfo +
> info in the .FDF file to calculate the offset of the Sec PE/COFF image. You
> can then load the binary into the debugger and disassemble. There are two
> things to look out for:
> 1) A Section in a FV File contains a section header, so make sure you are
> using the start of the PE/COFF image, and not the section header in front
> of the PE/COFF image
> 2) In general all images in edk2 are linked a zero. If the build tools
> produce an ELF or Mach-O file and convert it to PE/COFF then the image is
> linked at the size of the PE/COFF header. This is due to the PE/COFF header
> getting loaded into memory when the image is loaded, but the ELF or Mach-O
> headers do not get copied into memory. So for example you often have to add
> 0x240 to the load address to get symbols to work correctly. Think load
> address + link address.
>
> Given the start of the FV will be a branch to the SEC PE/COFF image entry
> point you should be able verify you are doing the math correctly.
>
> It may be possible to write a debugger script that loads the FD into
> memory, and then you can disassemble it with the given offsets. In gdb you
> may be able to use `restore Sec_ArmPlatform_EFI.fd 0xEC000000 0xEC00FFFF`.
> Don't forget to set the processor architecture in the debugger, and you
> may have to use 0 vs. the real address depending on what is legal virtual
> address space for an application on your build platform.
>
> For the ARM debugger there seems to be scripts to crack FVs:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
>
> Thanks,
>
> Andrew Fish
>
>
> On Nov 27, 2012, at 7:10 AM, James White wrote:
>
> Is there a way that I can disasseble my generated UEFI binary (in my case
> FV/SEC_RTSM_VE_CORTEX-A15_MPCORE_EFI.fd) so that I can see the exact
> instructions that are being run once the firmware is executed from ROM?
> Is there documentation about the format of that .fd? In my case I only
> have the Sec module in the binary but I can see that the .fd is not exactly
> the same as Sec/Sec/OUTPUT/ArmPlatformSec.efi - what is the difference?
> Can anyone recommend a good disassembler for ARM EFI binaries?
>
> Thanks for any pointers.
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
>
> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single web
> console. Get in-depth insight into apps, servers, databases, vmware, SAP,
> cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from
> $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________ edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
>
> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your
> parallel project right.http://goparallel.sourceforge.net
>
> _______________________________________________ edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
>
> http://goparallel.sourceforge.net_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
Thanks and Regards,
Shiva.
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
