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.

use syslink starting dsp application from u-boot

Hi all,

I'm working on a custom board based on omap l138. The board is working with linux 3.18 + syslink (with same minor patch on both side to work together).

Everything works well if linux using an application simular to the example sysloader load the dsp program.

The to reduce the boot time I start to work booting the dsp aplication from u-boot. I have patch uboot to start the dsp application and the patch is working well. The dsp start doing something.

The I start linux but the linux aplication is not able to connect to dsp app through syslink api because I have a fail calling

/* syslink: invoke the load callback */
status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, NULL);

what I have to do? It is normal to have that fail only because linux does not load the dsp application?

many thanks to any answer

  • Dear Michele,

    The I start linux but the linux aplication is not able to connect to dsp app through syslink api because I have a fail calling

    Have you loaded any application on DSP in u-boot before running DSP app in lInux ?


    Everything works well if linux using an application simular to the example sysloader load the dsp program.

    Able to run the DSP app on DSP core if u-boot doesn't use DSP app ?
  • Yes I'm able to start the DSP application on DSP core from uboot.

    The DSP do exactly what I want except comunicate with the linux aplication using the syslink api.

    I try to do exactly what is descrive in

    processors.wiki.ti.com/.../SysLink_Boot_Modes

    I have tested all the 3 possibility with the same dsp aplication:

    1. AppLoader         :   all works

    2. SlaveLoader       :   all works

    3. External loader   :   dsp application running on dsp code is working but linux is not able to communicate with it.

    I understood today that "case 3" I have to modify (in linux) the call of 

    status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, NULL);

    with

    status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, dsp__Ipc_ResetVector);

    where 

    dsp__Ipc_ResetVector = (void *)(0x....)

    and the address ... is

    readelf -s <elf file of dsp aplication> | grep _Ipc_ResetVector

    if I dont' modify the linux code the call on 

    status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, NULL);

    fails. If I change the linux code with

    status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, dsp__Ipc_ResetVector);

    the ipc_controll never return.

    Any Ideas? 

  • reading syslink code I have fond the issue. When linux call ipc_control with Ipc_CONTROLCMD_LOADCALLBACK the 3rd parameter has not to be 

    "the slave-side address of the _Ipc_ResetVector symbol" (like documented in version 2_10_05_26, http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/2_10_05_26/exports/syslink_2_10_05_26/docs/html/_ipc_host_8h.html )

     but has to be

    "a pointer to the slave-side address of the _Ipc_ResetVector symbol" (like documented in http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_ipc_host_8h.html 

    in the syslink code the 3rd parameter is double deferenced so it has to be a pointer to a pointer, and so the working call is

    status = Ipc_control(remoteProcId, Ipc_CONTROLCMD_LOADCALLBACK, &dsp__Ipc_ResetVector);

                                                                    ^

    regards,

    Michele