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: [email protected]
> Date: Tue, 27 Nov 2012 08:44:13 -0800
> To: [email protected]
> 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
> [email protected]
> 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
> [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
