Bootstrap plus application

Hi Andrew,

A quick answer is, we can translate .out file to hex dump file by hex6x.exe which is included in any CCS ang Code Generation Tools for C6000 series DSP.  The chapter 11 "Hex Conversion Utility Description" of SPRU186W (http://www.ti.com/lit/ug/spru186w/spru186w.pdf) covers this topic.

Once we loaded the code onto DSP memory, write-back cache to loaded memory if required, you can jump to the address _c_int00.  The section 7.10.1 "Run-Time Initialization" covers this.

If you have questions, please don't hesitate to ask us.

Best Regards,
Atsushi

Atsushi,

Thank you for your reply.  The documentation references were helpful.

I do have an issue with the linker that I don't understand.  I will be running a custom bootstrap that will need to branch into my main application code.  My application code will also need to branch back into my bootstrap code.  Because of this, I want to absolutely locate the _c_int00() function for each project so I have a fixed memory address that can be used to branch between the two apps.

I've tried to use the following linker option in my .cmd file (taken from spru186w.pdf - example 7-9, section 7.5.4.5)

SECTIONS

{

.rts: load = 0x00800000

  {

    -l=rts6600_ELF.lib <boot.obj> (.text)

  }}

in the hopes of fixing the address of the _c_int00() function but I get a linker warning:

  warning #10068-D: no matching section

How can I lock the location of a function from a library to I can reference it by value instead of by name?

Hi,

You could consider to directly use the ELF format produced by the linker for your application. The bootloader can read the ELF file from the flash and with a little work load it in memory and find out the entry point (it is coded inside the ELF file). I f you want to save space on the flash you can strip the debug symbols.

To go back to the bootloader you can chose:

• reserve a little memory area (anyway you have to reserve the aread used by the botoloader: you applicaiton cannot overwrite) that the bootloader will  fill with its return point
• or pass the addres in a CPU register and modify a little the application start routine to read the value and save it somewhere
• or, while interpreting the ELF, patch a reserved section so to write in the info you want

If you look at the source of the IBL you can find the source code to work on the ELF format.

About the linker: I don't know why, but referencing the RTS library with its full name doesn't work. Instead write rts*<boot.obj>(.text). Note that the "-l" is not required since the library is automatically used by the linker.

Some function from RTS library are included since they are  used by the compiler: for instance memcpy is sometime  used to copy strcuture (structure assignament) and by the ELF ROM autoinitialization code (copy of the initialized data), while exit() is automatically called when returning froma main().

Andrew,

I'm afraid but I'm not familiar with linker command file syntax.  But by some trials, I found the following example worked.

SECTIONS
{
    .text: { boot.*(.text:_c_int00) } > 0x00800000
}

This came from the following line in the .map file which linker generates.

.text      0    00800000    000000a0     
                  00800000    000000a0     boot.ae66 : boot.oe66 (.text:_c_int00)

Is this okay for you?

Best Regards,
Atsushi

Thank you both for your responses.  I now understand, and have been able to lock the location of the _c_int00 function.

Another related question - will the hex6x.exe utility automatically build in a DDR initialization table if I place code there in my linker file?  For some reason, I'm having headaches fully understanding the boot table format that needs to be programmed into the SPI Flash, not just for my special case, but in general.  I think I have it that the sections in my linker command file will each get generated into a boot table with a size, destination address, and code data, but I'm struggling with the idea of getting the DDR registers initialized properly.

If I declare (in my linker command file) a MEMORY section for the DDR, and make it (RX) to allow code execution, then locate some (or all) of my code to that area in a SECTIONS entry, will the hex6x.exe utility build the DDR initialzation table for me?

Hi Andrew,

Did you mean initialization of DDR interface or putting initial values in C global variables (like int a[5] = {1, 2, 3, 4, 5})?

To answer the former question (DDR interface initialization), you and your custom board designer need to read SPRUGV8C (http://www.ti.com/litv/pdf/sprugv8c).  Register configuration depends which exact DDR memory device you use and custom board circuit design.  If you use EVM, you will find DDR initialization code in provided GEL file and you can refer them.

By the way, we need to initialize DDR interface prior to load the code into DDR.

Regards,
Atsushi