Hex File Format, post process binary file possible?

More information:  I played around and noticed that it appears to be truly accounting. 

The data at offset 64, breaking up the alphabet is actually two 16-bit values, the 2nd is the actual count of bytes in 2nd half + 4 bytes (for the last 4-byte value that is always 0s). 

I'm still trying to "crack" the first value.  It appears to be 0xFFFF - 2nd value - the ones complement of the 16-bit values in 2nd half, or...some derivative of. 

Can you provide any documentation? 

Hi William,

Though I am not 100% certain, it is highly likely that your boottable file follows this structure:

Word Contents
1 10AA (KeyValue for memory width = 16bits)
2 Register initialization value or reserved for future use
3 Register initialization value or reserved for future use
4 Register initialization value or reserved for future use
5 Register initialization value or reserved for future use
6 Register initialization value or reserved for future use
7 Register initialization value or reserved for future use
8 Register initialization value or reserved for future use
9 Register initialization value or reserved for future use
10 Entry point PC[22:16]
11 Entry point PC[15:0]
12 Block size (number of words) of the first block of data to load. If the block size is 0, this indicates the end
of the source program. Otherwise another section follows.
13 Destination address of first block Addr[31:16]
14 Destination address of first block Addr[15:0]
15 First word of the first block in the source being loaded
... ...
... ...
. Last word of the first block of the source being loaded
. Block size of the 2nd block to load.
. Destination address of second block Addr[31:16]
. Destination address of second block Addr[15:0]
. First word of the second block in the source being loaded
. …
. Last word of the second block of the source being loaded
. Block size of the last block to load
. Destination address of last block Addr[31:16]
. Destination address of last block Addr[15:0]
. First word of the last block in the source being loaded
... ...
... ...
n Last word of the last block of the source being loaded
n+1 Block size of 0000h - indicates end of the source

Hope it would help,

Victor

Hi Victor,

     Yes, that aspect is documented in the Assembly user's guide.  But, I don't see this feature I'm currently seeing.  In this example below, I'm showing where the value changes again.  This time, 0x0080 is 128 bytes, and the 0xEB97 is 0xFFFF subtracting a 16-bit 1s complement of the 128 bytes that follow, minus 128 for the size. 

 Its not a valid load address, as my file has three boot sections, one at 0x804000 created by me, then the .text and .cinit section, which I've verified and found in my hex6x generated binary file.  The file boots from i2c EEPROM if I don't attempt modifications, so it must be a valid TI ROM Bootloader format.  

I suppose, if this can't be answered, is there an alternate way to have the TI ROM bootloader load specialized, post-build, data into SRAM during TI boot that can be put into the boot image?   

Processor: c6457, little endian.   

Thanks for any info. 

.cinit 0 00801940 00000054

.VERSION_INFO  00804000 00000060

.text 0 00801040 00000900

Valid Memory Ranges as defined in my linker command file:

MEMORY

{

IRAM: o = 0x00800000 l = 0x00004000

IRAM_RESERVED: o = 0x00804000 l = 0x0000400

}