This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM and elf format.

Note: This was originally posted on 3rd March 2013 at http://forums.arm.com

Hello
I'm analyzing some ARM boot loader codes and writing my own boot loader to use ARM trustzone and virtual extension on Cortex A15 using versatile express on Fast Model.But I couldn't understand some topics. I will very appreciate if someone could help me.

1. Many boot loader samples have their own linker script which is used in compile time. But I found that their entry point is located at a position far from 0x00000000.I learned that when processor is powered on, program counter points to zero, and exception vector is at the position. But when I loaded the sample boot loader, pc was pointing the entry point based on linker script, not zero. And even when an exception was occurred, it works very well, I mean, exception vector is located from the entry point, not zero.


2. Are their any relationships between elf format and ARM core?When i started model debugger in Fast model, I passed the file name of elf file I compiled. It has instructions in addition to the elf header and some other information.So it is not a pure code package. I think that the input file should be a pure code package. Addition information does not be needed. I think model debugger should read the pure binary file and load it to 0x00000000 and then power core on. But elf file works very well and pure binary does not work.


As I mentioned at first and second problems, I am supposing that there are some relations between elf format and ARM core or Fast model. I am very confusing. Does one vendor support specific format? I don' think so. But fast model reads elf format file and set the first pc location and start of the exception vector to the position elf format points.So I want to understand why real ARM core of Fast model are related to elf format and how initial value of pc and exception vector are changed based on elf file and linker script.
  • Note: This was originally posted on 4th March 2013 at http://forums.arm.com

    To ttfn.
    Thanks for your detail answer. I realized most of my problems. After I read your comment, I can understand the code more precisely Now I will find an way for running a binary file in the debugger to test in the more real-board similar environment.
    Thank you again.
  • Note: This was originally posted on 4th March 2013 at http://forums.arm.com

    When the processor comes out of reset, it will start executing at 0x0 or 0xFFFF0000.  Which address is normally hardwired or configurable depending on which part you are using.

    After reset, a TrustZone capable processor can have the vector at pretty much any address.  Software has to write one of the Vector Base Address registers (VBAR).  I suspect this is what the bootloader is doing in your example.

    What most "real" systems have is a multi-stage boot loader.  The first in ROM/flash at 0x0 (or 0xFFFF0000) which does very little - probably minimum initialization.  Then branches to the second stage (main) boot loader.  I think you're looking at the second type, hence it not starting at 0x0.

    The ELF contains the binary + symbolic information.  The symbolic information tells the debugger where in memory to load the image, and provides the necessary information for source level debugger (that is, this assembler instruction maps to this statement in this source file).  Most debuggers will also let you load a binary instead.