• Resolved

EABI Format Decoding for Bootloading

I was wondering if there was a document/utility or if I could get some get some help decoding the EABI file format for bootloading.  I've used the hex6x utility to successfully make a boot file, however, I'm in the process of making a secondary bootloader to load out of a large I2C device (3/4 byte addressing), and the one issue I currently have are the sections of code we need to prefill w/ 0x00.

I've used the ofd6x utility to successfully create a xml file, however I'm having an issue trying to find where the pre-fill values are.  Is there a document out there that describes the xml output (like the http://www.ti.com/lit/an/spraa64/spraa64.pdf for COFF files), for the EABI output?

  • Hi,

    The EABI produce and ELF file. IBL support ELF boot from NAND and NOR.  In mcsdk_2_00_01_12\tools\boot_loader\ibl You can find the source code to decode the ELF file and launch it. It seems it support dynamic relocation. If You don't use it, the parsing caould be simpler.

    To work on the .out files I'm using the IBL source code and ELF specification from http://refspecs.linuxbase.org/elf/elf.pdf.

  • In reply to Alberto Chessa:

    For generating the secondary bootloaders we have certain utilities. You can use the I2C boot examples for reference. C:\mcsdk2_0_7\mcsdk_2_00_07_19\tools\boot_loader\examples\i2c.

    Unfortunately, we don't have any document explaining the utilities yet.

    Please let me know if you have any issues decoding the examples.



    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • In reply to Alberto Chessa:

    Thanks for that link Alberto, that's exactly what I was looking for.


    I have looked at those bootloader examples, however we need to do a bunch of different initializations and are booting from a custom device (via I2c) so we're using a custom secondary boot (that was derived from a previous version we did for the 6474).

    One thing I was wondering about though was how does the primary bootloader configure uninitialized sections?  There are some libraries we are using that require uninitialized sections to be set to 0, but am not sure how the bootloader handles them.  

    According to the Assembly language tools document (spru186v) the hex6x utility to create boot tables will not include uninitialized sections (11.5).  We need some of these sections to be loaded by the primary bootloader (which will load into DDR3, setup by configuration tables).  Is there a different utility or a way to get hex6x to initialize these sections to 0?  Or can you tell me how the primary bootloader (built into the processor) handles these sections?


  • In reply to Erick Higa:


    The boot tables should include your .cinit  section that contains the instruction to initialize the initialized (by copy) and uninitialized data (by zero fill) -- see linker map file.

    This section in then processed by the the c_int00() initialization function (the default program entry point). The program must be build with the ROM autoinitialization model.