• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 461 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

hex6x/tiobj2bin-entry point query

Rajarama M Bhat
Intellectual 550 points

Hi,

We are using only dsp inside TMS320DA828 ,which has both ARM and dsp.Flash is connected to SPI1. We have a modified bootloader(modified DSP UBL) for DSP ,which does the booting only for DSP. Primary bootloader D800K005 copies DSP-UBL to shared RAM(L2) in a proper fashion. We also have burned application in flat binary image format inside flash. Application is a simple program which sets two GPIO pins. Here we are able to generate a map file using hex6x utility(tiobj2bin.bat) while generating the flat binary image. We are under the impression that if we load the flat binary image as it is, from the flash, we will be able to execute the application. There is only one .text and .cinit section in the application. We are giving .text starting address as the entry point of the application. DSP-UBL branches out to this entry point. We are using tiobj2bin with hex6x in following command:
%hexcmd% -map=test.map -b -image -o %binfile% %hextmp% %outfile%

The questions:
1)Is the approach correct?
2)If not is there a way to generate detailed map file of flat binary image (we are using -map=mapfilename.map in hex6x)?
3)What should be the entry point when we consider flat binary image?(we know that _c_int00 is the entry point for elf and coff images,but the coff&elf images are converted to flat binary image here,so is it possible for us to use the same entry point? ). Also,flat binary image's size is very less compared to elf image.
4)Does the flat binary image (in flash mode) do all the steps performed by debugger during debugging mode?

Thanks,

Rajaram

  • 0
    TI__Guru** 116770 points

    Hi Rajaram,

    The procedure to boot DA828 should be same as the procedure described here:

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L137

    You do not need to convert your application to flat binary image, instead you should pass it as the second input to AISGen tool on command line.By this way you will have one monolithic boot image with the the application being loaded in memory during ROM boot. Your bootloader DSP UBL can then jump to appropriate entry point (_cint00) in the application image.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 550 points

    hi Rahul,

    Thank you for the information.

    Primary bootloader d800k005 loads DSP-UBL to shared RAM ,right? Our image is larger than the RAM size. So it is difficult for us to have one monolithic image.Is it possible for us to make primary bootloader to load one monolithic bootable image to SDRAM alone (or shared RAM for dsp-ubl &SDRAM for application)?

    We have made it to work with flat binary image and entry point is _c_int00. We are loading the flat binary image to to starting location in .map file created from hex6x(though the addresses same as .map from ccs compilation, .map file from hex6x directly gives only the relevant section)

    Thanks,

    Rajaram

  • 0 in reply to Rajarama M Bhat
    TI__Guru** 116770 points

    Rajaram,

    The primary bootloader will load the binaries based on the section specification in the out files. Essentially you provide the linker command file when you build the binary so you can use the RAM  memory to load the DSP UBL while use the SDRAM for the Application and the primary bootloader should be able to place them in the right memory during boot.

    Good to know that you were able to make it work with the flat binary image as well.

    Regards,

    Rahul