• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1777 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.

Using Slaveloader with a custom DSP application (non SYSBIOS)

benjamin
Prodigy 70 points
Other Parts Discussed in Thread: SYSBIOS

We are developping a custom DSP code based on µC/OS2 for the DM8148
Instead of developping a custom loader we would like to evaluate one of the the syslink features, provided by the slaveloader tool (ProcMgr API).

The DSP code has been produced using CCSv5.5 and dsp compiler and can be successfully loaded using our JTAG probe and execution is successfull.

Now the focus is on slaveloader :

Syslink examples (GPP + DSP test binaries) are proprerly loaded and executed (frameq, ringio, ....).

Our questions are :

- what are the requirements for the DSP binary in order to use Slaveloader ? (binary size, memory segments definition on L2P or DDR, entry point address, linker command, COFF/ELF)

- what are the limitations on the slaveloader or Syslink ProcMgr ? memory mapping on the GPP (linux)

- Is sysbios mandatory or not for the usage of the Slaveloader/ProcMgr ?

Thanks for giviing detailled informations about this because no documentation is provided about this in the linux PSP.

best regards

--

benjamin

  • 0
    TI__Genius 12865 points

    Hi Benjamin,

    Slaveloader can load non-BIOS executables that do not use IPC to communicate between processors. For DM814x devices, the DSP binary needs to be of ELF format. It should be compiled with --abi=eabi and be linked using these options: --dynamic -u _c_int00 --abi=eabi. This is so that it can be loaded dynamically using the ELF loader in SysLink.

    There is no known limitation to its memory map. Obviously it must not conflict with the memory that is used by the Linux host.

    There is an example in Syslink 2.21.03 that illustrates how a non-BIOS DSP executable should be built in order to be loadable by slaveloader. You can find it under <SYSLINK_INSTALL_DIR>/src/examples/archive/TI814X_linux_elf/ex64_metal.zip.

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Prodigy 20 points

    Hi Vincent,

    We have run the DSP ex64_metal example that is provided in the syslink installation directory:

    -          Generate the dsp binary, load it and execute it using slaveloader

    -          Using CCS, check that the dsp binary is loaded in DDR (at @ 0x9F000000) , check that the _c_int00 symbol is located at @ 0x9F001400, check that the PC is located in the while (spin) of the main_dsp.c

     

    Then we want to load and execute the ex64_metal in L2 RAM , not in DDR:

    -          Modify the linker.cmd file as following: DSP_PROG (RWX) : org = 0x00800000, len = 0x40000

    -          Generate  the dsp binary, load it and execute it using slaveloader

    -          Using CCS, check that the dsp binary is loaded in L2RAM  (at @ 0x00800000) , check that the _c_int00 symbol is located at @ 0x00801400

     

    But it seems that the ex64_metal binary is not executed correctly : when the CCS connects to the dsp target, the PC is not located in the while (spin) of the main_dsp.c

     

    What do we have to do to load and execute correctly the ex64_metal in L2 RAM ?

    Could you explain why the option –u _c_int00 is mandatory ?

    Marie-Claude

  • 0 in reply to Marie-Claude Mutschler
    TI__Genius 12865 points

    Hi Marie-Claude,

    You need to use the L2 RAM's global address as opposed to its internal one. You can simply change dsp/linker.cmd to load the code to IRAM:

        .text: load >> IRAM

    This corresponds to the L2 RAM's global address, as defined in Table 2-5 in http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf.

    You are correct that '-u _c_int00' is not compulsory in this case. I can see that the example works fine without it. It is simply there to ensure _c_int00 is in the symbol table.

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Prodigy 20 points

    Hi Vincent,


    I have changed the linker.cmd to load the code in internal RAM of DSP using the global address 0x10800000.

    Using slaveloader to load and execute the DSP binary is OK.

    Thanks for your answers.


    MC