• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 517 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.

DSP/BIOS Link debugging GPP application on Linux

Bastian
Intellectual 430 points

Hello,

I try to debug a application using DSP/BIOS Link on Linux.

I found that DSP/BIOS Link make use of threads (pthreads ?).

So it's difficult do use the gdb! Gdb hangs after evocing a thread.

The questions are:

How to debug a DSP/LINK bios app on Linux?

How to debug a DSP/LINK bios app on Linux with gdb?

Is there a DSP/BIOS Link port that uses the poll/select mechanism instead of threads, which would be a clean

implementation for a deterministic Linux programm.

Is it possible to modify or port DSP/BIOS Link on ARM-side for using the poll/select systemcalls?

Are there some activities in that way?

Thank you very much.

  • 0
    TI__Expert 4930 points

    Hello,

     

    Please find my answers inline:

    >>I found that DSP/BIOS Link make use of threads (pthreads ?).

    [Deepali]: Yes, internally we create a thread using pthread. This is an internal thread used to process and implement notification between ARM and DSP.

    >>So it's difficult do use the gdb! Gdb hangs after evocing a thread.

    [Deepali]:Some links here:

    http://www.delorie.com/gnu/docs/gdb/gdb_25.html

    http://www.yolinux.com/TUTORIALS/GDB-Commands.html

    http://www.delorie.com/gnu/docs/gdb/gdb_40.html

    Does n't the gdb support multi-threaded debugging for you?

    >> How to debug a DSP/LINK bios app on Linux?

    [Deepali]: Some generic tips and trips here:

    http://wiki.davincidsp.com/index.php/Debugging_DSPLink_using_SET_FAILURE_REASON_prints

    http://wiki.davincidsp.com/index.php/Debugging_DSP_side_using_DSPLink_NOTIFY_module

    >>Is there a DSP/BIOS Link port that uses the poll/select mechanism instead of threads, which would be a clean implementation for a deterministic Linux programm. Is it possible to modify or port DSP/BIOS Link on ARM-side for using the poll/select systemcalls?

    [Deepali]: DSPLink is available as a porting kit. So, modification or port to any design is possible. We have no efforts in that direction. We feel a dedicated internal thread for handling events is an efficient with less system loading. However, I would like to understand why you choose a poll/select system calls?

     

    Deepali


  • 0 in reply to Deepali Uppal
    Intellectual 430 points

    Hello,

    thanks for your answer!

     

    >>[Deepali]:Some links here:

    >>http://www.delorie.com/gnu/docs/gdb/gdb_25.html

    >>http://www.yolinux.com/TUTORIALS/GDB-Commands.html

    >>http://www.delorie.com/gnu/docs/gdb/gdb_40.html

    >>Does n't the gdb support multi-threaded debugging for you?

    Thank' s for this links, i' ll check these links soon to get my multithreaded dsp/link app's debugged with gdb.


    >>[Deepali]: Some generic tips and trips here:

    >>http://wiki.davincidsp.com/index.php/Debugging_DSPLink_using_SET_FAILURE_REASON_prints

    >>http://wiki.davincidsp.com/index.php/Debugging_DSP_side_using_DSPLink_NOTIFY_module

    This is doubtless an option.

    This sounds a little bit like printf - debugging.

    With printf - debugging i got my bug solved, which pointed me to this issue (this forum thread), but it is not convenient.


    >> However, I would like to understand why you choose a poll/select system calls?

    A Linux process using the poll/select systemcalls offer a way to block for many actions without multithreading headaches!

    This is advantageous in debugging this process with gdb on the target, its very straight forward.

    There is no danger for strange behaviour and difficult bugs because of multithreading issues. There is nothing to protect with semaphores or mutexes.

    In my opinion via poll/select systemcalls it's a clean and first of all a deterministic way to get things done.

     

    >> [Deepali]: DSPLink is available as a porting kit. So, modification or port to any design is possible. We have no efforts in that direction. We feel a dedicated internal thread for

    >> handling events is an efficient with less system loading.

    I' ll look at the porting kit, but i think i don't have enough resources to get a port for that done.

    I feel: an implementation of dsp/bios link without threads would be a great benefit, more "unix - like" and a better choice for the Linux-port.

    Of the "system loading" point of view, i can imaging that the poll/select systemcalls are very efficient, too. (perhaps more efficient?!)

    Please discuss this in your team! Perhaps your are well-disposed to do some efforts after that?!

    Regards Bastian.

     

  • 0 in reply to Bastian
    TI__Expert 4930 points

    Bastian,

    We reached the current design after a lot of thought/prototyping to achieve the design needs of the NOTIFY protocol. The interrupt sent to DSP is received in the Linux kernel and we need a a way of asynchronously ensuring delivery of the interrupt and the payload to the correct process in a multiprocess/multithread application.

    I am not aware of how poll/select works in detail so I cannot comment whether it would be a good replacement.

    Currently, we have no plans of changing DSPLink design internally.But if we do so, I will look into what you have suggested.

    Deepali