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
