• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 1653 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.

OpenMP + MPM: How to get traces on the ARM core

David Beaulieu
Expert 1280 points

HI, 

I have been able to run the OpenMP examples from the Processor SDK RTOS on the evm-k2h.

Now, I am trying to integrate with MPM so that I can push the binary to the DSP from the ARM and also get the traces in the  /sys/kernel/debug/remoteproc/ file system. 

I have followed the steps in the MCSDK user guide () and added the following in the SYS/BIOS configuration:

Program.global.sysMinBufSize = 0x8000;
var System = xdc.useModule('xdc.runtime.System');
var SysMin = xdc.useModule('xdc.runtime.SysMin');
System.SupportProxy = SysMin;
SysMin.bufSize = Program.global.sysMinBufSize;

var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.loadSegment = Program.platform.dataMemory;

However, I am not able to get that to work. The binary seems to be pushed to the DSP properly but can't get the traces to work. 

Is this supported with OpenMP?

Regards,

- David

  • 0
    TI__Guru**** 161600 points
    Hi David,

    I've forwarded this to the design team. Feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Genius 12805 points

    David

    Before you start a relative complex example,  can you try and usu MPM to download a simple code to the DSP. and see if you can reset the DSP, download the code, run the code and get back the trace

    1. What version of the code you use?  The location of the trace was changed in different MCSDK versions

    2. If you do not have a simple example to look for the trace and there is no example in teh release get back to here. I can provide you with example

    Ran

  • 0 in reply to ran35366
    Expert 1280 points

    Hi Ran,

    I already have a simple example working with MPM. I have actually modified the PCIe examples to work with MPM as well without any issues. 

    I am using Processor SDK 03.00.00.04.

    Is it possible to get it OpenMP & MPM traces to work together?

    Regards,

    - David

  • 0 in reply to David Beaulieu
    TI__Genius 12805 points
    Good, so it is not the MPM itself

    What may be the issue?
    One difference between a standard DSP code and OpenMP is that in OpenMP the master DSP initiates the execution of the slave DSP (do you agree?) and not the ARM. Core 0 (which is usually the master DSP) is completely controlled by the MPM, so at least we expect to see the tracing from Core 0
    Other issue might be the size and the location of the shared memory. Is it possible that the messages exchange between the MPM and the cores overwrite (or underwrite) messages between DSP cores? (I need to investigate it)

    So here is what I suggest - try very simple OpenMP program - Hello World time with printing to the trace and see if you can see the trace of core 0, and then if you see the trace of any other cores. Based on this observations we will see what is teh next step

    Ran
  • 0 in reply to ran35366
    Expert 1280 points
    Hi Ran,

    I've tried that and I don't get the traces for any of the processors. Neither from the master thread (DSP core 0) or the other cores.

    FYI, I am not running OpenMP on the ARM in this example. I am only running OpenMP on the DSP cores.

    Regards,
    - David
  • 0 in reply to David Beaulieu
    TI__Expert 3350 points

    David,

    I've noticed that the buffer used by trace (xdc_runtime_SysMin_Module_State_0_outbuf__A, referenced in ipc_3_43_01_03/packages/ti/ipc/remoteproc/rsc_table_tci6638.h) must be placed in L2SRAM for trace to work. 

    Can you check if xdc_runtime_SysMin_Module_State_0_outbuf__A is placed in L2SRAM in your DSP binary?

    Ajay

  • 0 in reply to Ajay Jayaraj
    Expert 1280 points

    Hi,

    I see the symbol in the MAP file being loaded @ address 0x0084ae70 which is L2SRAM.

    Could it be the memory range definition?

    The MCSDK documentation is saying we need to have the following defined to have MPM to work:

    L2 Local 0x00800000 1MB

    L2 Global 0x[1-4]0800000 1MB

    MSMC 0x0C000000 6MB

    DDR3 0xA0000000 (512MB)

    However, I have modified the platform to get the OpenMP examples to work:

    Could that be the issue? I have followed the steps from here () to configure the platform for OpenMP. 

    Let me know,

    Regards,

    - David

  • 0 in reply to David Beaulieu
    TI__Expert 3350 points
    David,

    Can you confirm a couple of things:
    1. Is the OpenMP DSP binary loaded and running successfully?
    2. After the DSP binary is running, has the trace file, /sys/kernel/debug/remoteproc/remoteproc0/trace0, been created on the EVM filesystem?

    The trace functionality is provided by the remoteproc module, not mpm.

    Ajay
  • 0 in reply to Ajay Jayaraj
    Expert 1280 points

    1. Is the OpenMP DSP binary loaded and running successfully?
    I know the DSP binary is working when I push it using Code Composer. However, I don't know if it is working when pushing the binary using mpmcl since I was relying on the console ouput / traces to know if it was working.

    2. After the DSP binary is running, has the trace file, /sys/kernel/debug/remoteproc/remoteproc0/trace0, been created on the EVM filesystem?
    No, the file was not created. 

    Regards,

    - David

  • 0 in reply to David Beaulieu
    TI__Expert 3350 points

    For #1, an option is to load/run the binary using mpmcl and then connect to the DSP using CCS. Once you connect, you can halt the DSP, load symbols from the binary file and see where the DSP is in it's execution. If you're unable to connect to the DSP using CCS (i.e. CCS complains that the DSP is held in reset), it is likely that load/run via mpmcl failed.

    Ajay

  • 0 in reply to Ajay Jayaraj
    Expert 1280 points

    Hi Ajay Jayaraj (256126) ,

    Sorry for the delay in responding to you. I got caught up with other issues and I just got back to look at this issue.

    So, I've tried #1 like you recommended. And now it seems the mpmsrv application is crashing when loading OpenMP application on the DSP.

    I have reduced my application to the openmp Hello World application (openmp_dsp_k2x_2_03_01_00/packages/examples/hello_with_make).

    Here is the backtrace of the mpmsrv application:

    #0  memset () at ../sysdeps/arm/memset.S:35
#1  0x00016424 in mpm_load_segment ()
#2  0x00016998 in map_and_copy_segment ()
#3  0x000192d4 in DLIF_allocate ()
#4  0x00022144 in load_static_segment (handle=0x53780, fd=0x41f70, dyn_module=0x538c8) at DLOAD/dload.c:691
#5  0x00024518 in dload_static_executable (handle=0x53780, fd=0x41f70, dyn_module=0x538c8) at DLOAD/dload.c:2243
#6  0x00024c5c in DLOAD_load (handle=0x53780, fd=0x41f70) at DLOAD/dload.c:2746
#7  0x00018470 in mpm_dlif_load ()
#8  0x0001612c in mpm_load_slave ()
#9  0x000155fc in mpm_ssm_state_reset ()
#10 0x00015378 in mpm_ssm_event ()
#11 0x00019cd8 in mpm_server ()
#12 0x00012fa0 in mpm_start_server ()
#13 0x000135d8 in main ()

    Regards,

    - David