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.

malloc() on dsp side?

Dear experts,

I am porting JM decoder into DSP side. I am using Codec engine right now, I just put all decoder into "example/codecs/viddec_copy/".

and compiling is successfully. However, the problem is that when I am using "malloc()" , i found that it does not work through, any suggestions? thanks very much, 

The examples like this:

=============== 

void ParseCommand(InputParameters *p_Inp, char *inBuf)

{

f = fopen (filename, "r");

FileSize = ftell (f);

content = malloc (FileSize + 1);

 FileSize = (long) fread (content, 1, FileSize, f);

 content[FileSize] = '\0';

 fclose (f);

 ParseContent (p_Inp, Map, content, (int) strlen (content)); 

}

================

void ParseContent (InputParameters *p_Inp, Mapping *Map, char *buf, int bufsize)

{

.

.

  char *bufend = &buf[bufsize];

.

.

.

}

=================

However, when running it on board, the following error occurs:

"DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0x78729560]."

If I change "bufsize" to "0", like "char *bufend = &buf[0];" in the second function, which does not give the error above.

I guess the "content = malloc (FileSize + 1);" did not work, am I right?

 

Regards,

 

David

 

 

 

  • Hi David,

    From your message, it was not clear as to where the functions 'live' (on the DSP or ARM? I am assuming you have an ARM core given you are posting on the Linux forum). The error message is trying to say that the DSP is accessing a memory address that is not valid (ie. outside of the range mapped by the DSP MMU). I can imagine this happening if ParseCommand is running on the ARM and it attempts to pass the address allocated by malloc to the DSP and then the DSP tries to access it. In this scenario, Codec Engine provides an API called Memory_alloc that you should be using instead to allocate from a shared memory pool (managed by the CMEM module).  See the Codec Engine example apps (e.g. video_copy) for details.

    Alternatively, if both functions are running on the DSP, that means malloc allocated memory from an invalid region. Assuming this is code inside your decoder, in general the use of malloc is not a good idea anyway. This is because Codec Engine was designed to work with XDM/XDAIS-compliant algorithms, and the XDAIS standard says that memory should be allocated through the IALG interface, so that memory allocation can be handled by the Codec Engine framework (and it will make sure it is done correctly). In this case my advice for you is to read up on the XDAIS IALG interface and implement it for your algorithm. In fact viddec_copy implements it as well (see VIDDECCOPY_TI_alloc). The XDAIS API is detailed in http://www.ti.com/litv/pdf/spru360e.

    Btw, this is a good tool to use for creating a 'template' to start from for your algorithm:

    http://processors.wiki.ti.com/index.php/Codec_Engine_GenCodecPkg_Wizard_FAQ

    Hope this helps,

    Vincent

     

  • Hey, Vincent,

    Your answer is very helpful to me, here is my situation now:

    1. The functions live in DSP side only.

    2. In order to speed up H.264 decoder, I am puting all JM decoder inside DSP side.  If I partition JM decoder into ARM and DSP sides, which will increase communication overhead, right? the other reason is that I am not familiar with XDAIS and IALG interface.  Simply speaking, I just replace "examples/codecs/viddec_copy.c"  with all JM decoder .c files. Is this solution feasible? 

    3. malloc():  based on above solution, inside JM decoder, many .c files originally contain "malloc()" , such as "ParseCommand()" function in the example of last post. According to your suggestion, there are:

    a). better to use XDM/SDAIS-compliant algorithm to handle malloc(). For now, I think it will take me long time to figure it out, also, it will come back and forth b/w ARM and DSP, which also increase communication overhead. am i right?

    b). If I keep all of "malloc()", and use them as original. What about the result? It will functional works or not? 

     

    BR,

     

    dave

     

  • Hi Dave,

    Regarding communication overhead, it really depends on the frequency you invoke your decoder. If you invoke it from the ARM 30 times a second, I'd argue the overhead is fairly small assuming you optimize the overhead introduced in dealing with cache coherency. If you invoke it thousands of time a second, then the overhead could become prohibitive. A good wiki topic on CE overhead is: http://processors.wiki.ti.com/index.php/Codec_Engine_Overhead.

    I recommend making your algorithm XDAIS-compliant, because CE was designed for compliant algorithms. It maximizes interoperability with other algorithms in your system (e.g. if you are using other TI codecs), and most resources you will find on TI's wiki deals with compliant algorithms, so you are likely to get better support. XDAIS algorithm leaves memory and resource allocation up to the framework. It declares its memory requirements using the IALG interface, so when you modify viddec_copy.c, you need to make sure you implement the IALG functions correctly.

    However, you are certainly free to choose your route. :) If you want to do your own memory allocation, I recommend you read up on DSP/BIOS, the RTOS on the DSP (sorry, you can't avoid learning new things). Typically I prefer to use the MEM_alloc API in BIOS to do memory allocation, as it 'fits' better with the rest of the system if you are using CE. If you insist on using malloc, you'd need to configure DSP/BIOS so that it assigns a memory segment from which malloc can allocate memory (hint: read up on the MEM module). The DSP/BIOS forum should be able to better assist you if you have any questions regarding this.

    Best regards,

    Vincent

  • Hey, Vincent

    It is appreciated for this great comments, I am eager to learn any new stuff. The thing now right is that I have very urgent time deadline .

    For me, I want to make the JMdecoder functional work on CE, and then I can make it XDAIS compliant later on.

     

    Today, I am trying the CE IUNIVERSAL_Examples . I already made change for the dirs in Makefile 

    However, I got the following errors when I build it:

    ==================

     

    fir_ti_filter.c:18:20: error: string.h: No such file or directory

    fir_ti_filter.c: In function ‘FIR_TI_filter’:

    fir_ti_filter.c:71: warning: incompatible implicit declaration of built-in function ‘memcpy’

    gmake[1]: *** [package/lib/lib/fir_ti/fir_ti_filter.ov5T] Error 1

    gmake: *** [packages/ti/sdo/algos/fir,.libraries] Error 2

    make: *** [codecs] Error 2

     

    ===================

     

    It is very weired, any helps?

     

    BR

     

    david

     

  • David,

    It looks as though you are building the algorithm code (fir_ti_filter.c) with the ARM build system as you are using gmake and generating an .o5T object file. This is DSP code and so must be build with C6000 compiler via CCS.

    Check out http://processors.wiki.ti.com/index.php/C64x%2B_iUniversal_Codec_Creation_-_from_memcpy_to_Canny_Edge_Detector for details. The code release is not yet on the external web so if you send me a message I can mail you it.

    Iain