The following question was submitted by hansr to the LH79520-10 site. It applies to the LH7A400-10 as well. Refer to the LH79520-10 post for original.
question: How do I get elf files generated by ARM or Greenhill tools to download to the development kit?
The ELF loader needs to know the address in memory where it should
place the incoming binary file. The Greenhill and ARM tools place this
information at the very end of an ELF file. When downloading over a
non-random access device, such as a serial port, it is impossible to
access this information until the entire file has been transferred, at which
point it is impossible to rewind the binary stream to access the file's
contents. The solutions to this problem are one of the following:
option 1: Load the file off of a random access device, such as a Compact
Flash card (which is currently the only random access device we support).
option 2: Move the "elf program header" to the beginning of the file.
One way to do this is to use the GNU binutils (arm-elf) package to recreate the
binary image with the elf headers at the -front- of the file. for example:
arm-elf-objcopy -O binary ELF_FILE_FROM_GREEENHILL.elf temporary_file.raw
arm-elf-ld -s -o REFORMATTED_ELF.elf -b binary temporary_file.raw -Tdata 0x40000 -Ttext0x40000
Where the arguments to the -Tdata and -Ttext parameters tell the linker
how to setup the headers of the newly created file. These values can be found
in the output of
arm-elf-objdump -x ELF_FILE_FROM_GREENHILL.elf
ARM-elf or Greenhill-elf downloads further explained:
here's a better description of what's going on...
The first step of the process removes all metadata from the file, including load addresses, all section information, any sections not marked LOAD or ALLOC, start address info, etc... What remains is a bare binary file containing what would have been loaded into memory, basically a memory image.
The second step takes that binary memory image and slaps on an elf header -- at the /beginning/ of the file so that the serial loader can load it. It just creates a new elf file with a huge data section whose contents are the loadable portion (including executable code) of the old elf file. The parameters for Tdata and Ttext tell the linker where to put this section in the new elf file, and where the start address should be, respectively.
So, if the old elf file's first loadable section (marked LOAD or ALLOC) was at 0x200c0000 and the start address was at 0x200c0000, then the parameters for Tdata and Ttext would be 0x200c0000 and Tdata would also be 0x200c0000.
See the binutils manuals at http://sources.redhat.com/binutils/docs-2.12/
for more information.