Issue with hex6x utility creating binary file from ELF out

Read about the hex utility in the C6000 assembly manual.  Read up on the ROMS directive in particular.  In this case, any section past 0xD0000000 is not converted to hex.  I'm not sure if that is happening to you, but it might be.  

Also, why do you use the option -boot?  If you are not sure why it is there, try removing it.

Thanks and regards,

-George

Anand,

anandk said:

As long as all of the .text section is in MSMCRAM it brings the code into the binary but any portion of the .text section that is moved to DDR3 is left out of the .btbl file.

Can you elaborate on this a bit more? When you say a portion of the .text section is moved to DDR3, do you mean a section that has a different load and run address or do you mean a custom named code section that is allocated to DDR3?

Does the memory range in the ROMS directive encompass the entire memory range to which all initialized sections are allocated? It might help if you could attach your link map file, and if possible the .out file as well so we can reproduce the behavior at our end.

Aarti,

I am trying to create a boot image to be loaded using an external host according to the instructions in-

..mcsdk_2_00_02_14\tools\boot_loader\examples\pcie\linux_host_loader

The output it creates is just a set of sections that contain {address, size, contents } for each section, which the host uses to load to the device over PCIe using the appropriate BAR. Based on this, I just tried to setup the ROMS directive to include the entire memory range to include all the initialized sections as you mention. DDR3 starts at 0x8000_0000.

The .text section is broken into two in the map file (simpler use case of ALL functions moved DDR3 - where none of them end up in the "boot table")

1. cinit resides in LL2 as required by SYS BIOS

.text:_c_int00
*          0    00820000    000000e0     

2. Other sections in DDR3
.text      0    08000000    001d3360     

#1 makes it into the boot table but #2 does not !!

Here is the summary memory configuration - I can email the complete map / out file if this is needed. (unable to attach it here).

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2_FAST_SCR           00800000   00037800  000000e1  0003771f  RW X
  L2SRAM                00837800   00008800  00006dba  00001a46  RW X
  MSMCSRAM              0c000000   00400000  003a9a5a  000565a6  RW X
  DDR                   80000000   00300000  00102800  001fd800  RW X
  DDR_HEAP              80300000   1fd00000  00000000  1fd00000  RW X

Thanks

Anand

(As is clear, I am not trying to use the utility for making different load and run addresses for any section.)

The above memory config is when all of the code section is in MSMC (except cinit). When it is moved to DDR, here is the config -

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2_FAST_SCR           00800000   00037800  000000e1  0003771f  RW X
  L2SRAM                00837800   00008800  00007416  000013ea  RW X
  MSMCSRAM              0c000000   00400000  00214536  001ebaca  RW X
  DDR                   80000000   00300000  002e5340  0001acc0  RW X
  DDR_HEAP              80300000   1fd00000  00000000  1fd00000  RW X

Another correction - #2 above is actually offset from the start of DDR. The sections before this (0x8000_0000 to 0x801027ff) are UNINITIALIZED.

.text      0    80102800    001db760     

Thanks

-Anand

George Mock said:

Read about the hex utility in the C6000 assembly manual.  Read up on the ROMS directive in particular.  In this case, any section past 0xD0000000 is not converted to hex.  I'm not sure if that is happening to you, but it might be.  

My interpretation of the manual and ROM directive is that it specifies the ROM address that will store the boot image, not the address range of the boot image contents. With this directive, hex6x produce a file from origin to programt he ROM. Inside there are all the segment of the image, with their load address that are no related to the ROM directive address.

Is that correct?

Based on parts of the linker map file you show, I can't see why the hex utility would not convert all the sections.  You could try to get us a test case we can use to reproduce this behavior ourselves.  But I think you would have better luck working with the people who created that MCSDK example you are using.  Consider starting a new thread in the Keystone Multicore Forum.  

Thanks and regards,

-George

George,

I created the MCSDK example mentioned in the past. I used hex6x to convert an out file into .btbl format and further into a header array. The exmaple code was simple and all the program is placed at one place (e.g., all in L2, or all in DDR3) and didn't meet any issue.

Customer's application is rather complicated and code is placed in L2, MSMC and DDR3. With the attached files, I ran the hlit_hex.bat file using CGT 7.4.1 and I was able to see the same issue, only code in L2 and MSMC were in the .btbl file. I think this is a tool problem. I am not an expert for the toolset. Can you help?

Regards, Eric

George,

Your second suggestion seems to work for us.

Thanks

-Anand