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.

DSP Link 1.65.01.06[dsplinkk.ko] on Linux kernel 3.13

Other Parts Discussed in Thread: OMAP3530

Hi,

After successful loading the DSP Link 1.65.01.06[dsplinkk.ko] on Linux kernel 3.13 version on omap3530 processor based board, we ran the following example

/opt/gpp/BIN/Linux/OMAP3530/DEBUG/messagegpp  /opt/dsp/BIN/DspBios/OMAP3530/OMAP3530_0/DEBUG/message.out 1 0

after executing the messagegpp ,  Linux system is not responding to any command.

we have set mem=100M at u-boot boot arguments

Could you please  let me know any solution to fix this issue?

  • Hi

    Hi,

    Here is more information , continuation to above thread

    While Execution/run time:

    when running ls command , we have seen  

    INFO: task kjournald:845 blocked for more than 120 seconds.

    From the source code:

    Here is the some more information, from DSP Link 1.65.01.06 ,file isr.c

    function : EXPORT_API DSP_STATUS  ISR_Install (IN  Void *      hostConfig,  IN  IsrObject * isrObj)

     osStatus = request_irq (isrObj->irq + 16,  (Void*)&ISR_Callback, IRQF_NO_THREAD,  "DSPLINK",                                   (void *)isrObj) ;

    Here we have added  "isrObj->irq + 16" offset of 16 , because in 3.13 kernel  file: arch/arm/mach-omap2/omap_hwmod_3xxx_data.c

    static struct omap_hwmod_irq_info omap3xxx_mailbox_irqs[] = {      { .irq = 26 + OMAP_INTC_START, },};

    could you please suggest solution to fix the issue.

  • Hi Alexander,

    You are trying to run DSPLINK with a version of Linux on which it has never been validated. The last version of Linux supported by DSPLINK was 2.6.37. Beyond that we can only give you limited support. So a good thing would be to first make sure you can run the DSPLINK examples correctly under Linux 2.6.37 to ensure you have a solid working baseline, before you dive into 'uncharted territory' and port the software to Linux 3.13.

    Given you are facing a hang in the messagegpp example, I'd suggest you first try to do some debugging on the ARM, and see if you can isolate the function call in the app that causes the system to hang. This will give you a better indication of where to look for the root cause of the hang.

    I do not have intimate knowledge of the Linux kernel code you are referring to, so I don't see why you need to add an offset of 16 to the irq being requested. But if you feel there is truly a need to do so, a better place to make that change would be in the ipsTable defined in the file config/all/CFG_OMAP3530_SHMEM.c:

    STATIC LINKCFG_Ips LINKCFG_ipsTable_00 [] =
    {
    {
    "IPS", /* NAME : Name of the Inter-Processor-Signaling component */
    (Uint32) 32, /* NUMIPSEVENTS : Number of IPS events to be supported */
    SHAREDENTRYID0, /* MEMENTRY : Memory entry ID (-1 if not needed) */
    (Uint32) 26, /* GPPINTID : Interrupt no. to used by the IPS on GPP-side. (-1 if uni-directional to DSP) */
    (Uint32) 55, /* DSPINTID : Interrupt no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */
    (Uint32) 5, /* DSPINTVECTORID : Interrupt vector no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */
    (Uint32) 50000000, /* ARGUMENT1 : Poll value for which IPS waits while sending event (-1 if infinite) */
    0 /* ARGUMENT2 : Second IPS-specific argument */
    }
    } ;

    The GPPINTID should correspond to the value of the irq that will be requested in request_irq() on receiving a notification from the DSP. In this manner you won't affect the behavior of ISR_Install() when it is trying to plug other interrupts.

    Best regards,

    Vincent