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.
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:
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?
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.
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.
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.
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?