• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 721 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.

TMS320C6748: Calling of code in ROM boot loader

Michael Greenspan
Intellectual 575 points

Part Number: TMS320C6748

We are operating a C674x DSP on a number of different custom cards with our only non-volatile memory being a large SPI flash.  At address 0 of this SPI flash we have our own custom boot loader which among other things provides a means of transferring AIS files (code and data) via different communications links, programming the AIS to the SPI flash at a specific location, and then loading that code and data to the DSP RAM and transferring control.

This all works very nicely.  We build our images (both boot loader and main code) using your AIS generation tool.  We program the custom boot loader (with UART boot mode) using your UartHost.exe program.  It is really a very nice set of tools, thank you, but there is one fly in the ointment which perhaps can be fixed/improved.

At the moment, the custom boot loader must contain code that reads AIS from the SPI flash, parses the AIS, and then executes the various AIS functions (primarily loading code to RAM of course, but also some of the other AIS functions). However, it seems a shame to do it this way, since the ROM loader already has all the code for this purpose, fully debugged, performing all AIS functions, 

My question: Is there a way that after my custom boot loader has done what it needs to do, it can pass an SPI flash address to the ROM loader and transfer control to the ROM loader, and it would do all the parsing of the AIS and all the AIS functions?  I would think that this would be helpful for a lot of users, and perhaps it is available, but I have read through an awful lot of reference material and cannot find a documented way to do this.

Even if this is not a planned-for and documented mode of operation, perhaps someone with access to the source code of the ROM loader could tell us a register to place the SPI address and a location to jump to that could provide this functionality. 

Thanks. 

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru** 116870 points
    Michael,

    Thank you for describing your use case clearly and also for your feedback on the boot tools. It is refreshing for us to get all of the explanation in the very first post on the thread without having to ask a bunch of questions :)

    We unfortunately don`t provide the ROM symbol table for this device for a couple of reasons. The ROM for this device supports Secure boot and we are required to protect the ROM symbol location to prevent software with malicious intent to access the secure part of ROM. The second reason is that this approach is extremely support intensive to provide access to the ROM functions which are essentially black boxed since we don`t open up the source so no good way to debug when an error occurs.

    Having said that I still don`t understand why AIS format is mandatory for the design of your secondary bootloader. After the initialization is complete, the only function ROM does is copy the ELF binary application images from boot media and load it into device memory and pass control to the application by jumping to the entry point. This can be attained using any ELF loader or the Out2RPRC format that we provide with secondary bootloader that we provide in the secondary bootloader that we provide as part of Processor SDK RTOS:
    processors.wiki.ti.com/.../Processor_SDK_RTOS_BOOT_OMAPL13x

    The secondary bootloader also provides the source to parse and load the out2rprc formatted application image.

    Regards,
    Rahul

    PS: There is also the option to use boot table format which is supported by TI C6000 compiler Hex6x tool. but this generates flat binary which you can load as a binary blob.