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.

DSPLINK memory management

Other Parts Discussed in Thread: DM3730, OMAP3530

I need to run an image processing application on my DM3730 dual core (ARM/DSP).

I'm using dsplink 1.65.2.9 and first of all I wanted to try and configure the memory used for arm/dsp communications starting from the example loop.

When i try to call it with a buffer size <= 16384 (16kB) everything goes right but if I try with 16385 byte the application will return the following output:

================= Sample Application : LLOP ========

==== Executing sample for DSP processor Id 0 ====

Entered LOOP_Create ()

CHNL_allocateBuffer failed (output). Status = [0x8000800b]

Leaving LOOP_Create ()

etc...

If I further increase the buffer size (the threshold is something in between 400kB and 500kB) the application returns a different error:

================= Sample Application : LLOP ========

==== Executing sample for DSP processor Id 0 ====

Entered LOOP_Create ()

[11378.099792] Error: Configured pool size is insufficient for passed parameters.

[11378.099822] Check /dsplink/config/all/CFG_<PLATFORM>.c

POOL_open () failed. Status [0x80008013]

Leaving LOOP_Create ()

etc...

Now I tried to have a look at CFG_OMAP3530_SHMEM.c but couldn't find any memory size that is exactly 16kB or about 400-500kB.

Since I don't quite understand what the different fields should do I tried to enlarge some memory sizes in the CFG_OMAP3530_SHMEM.c and to do the corresponding changes in dsplink-omap3530-base.tci and rebuild the sample but the application keeps returning the same errors when fed with the same arguments.

I tried to modify the boot.scr file too, to reduce the amount of memory dedicated to Linux but nothing changed.

I'm not surprised that I couldn't figure out how to increase the memory that can be used for the arm/dsp communication, but I can't understand why the application behaves in the same exact way even if I change the memory tables.

Now, I'd really appreciate if someone could tell me in the easiest way what are the steps that I should follow to e.g. increase the buffer size limit from 16kB to 32kB. It would be a great point to start from in order to understand how to manage the memory tables.

Thanks,

Filippo

  • Hi Filippo,

    Error code 0x8000800b corresponds to DSP_EINVALIDARG according to gpp/src/inc/usr/errbase.h. Looking at the code in gpp/src/ldrv/ldrv_chnl.c, I see that it may be returned by this code in LDRV_CHNL_allocateBuffer:

    if (size > LDRV_CHNL_Object [procId][chnlId]->maxBufSize) {
        status = DSP_EINVALIDARG ;
        SET_FAILURE_REASON ;
    }

    Could you verify that you have increased the MAXBUFSIZE field in this structure from CFG_OMAP3530_SHMEM.c?

    STATIC LINKCFG_DataDrv LINKCFG_dataTable_00 [] =
    {
    {
    "ZCPYDATA", /* NAME : Name of the data driver */
    0, /* BASECHANNELID : Base channel ID for the driver */
    16, /* NUMCHANNELS : Number of channels supported */
    16384, /* MAXBUFSIZE : Maximum size of buffer supported (-1 if no limit) */
    SHAREDENTRYID1, /* MEMENTRY : Memory entry ID (-1 if not needed) */
    0, /* POOLID : Pool id for allocating buffers */
    1, /* QUEUELENGTH : Queue length for the data driver */
    0, /* IPSID : ID of the IPS used */
    1, /* IPSEVENTNO : IPS Event number associated with data Driver */
    0x0, /* ARGUMENT1 : First data driver specific argument */
    0x0 /* ARGUMENT2 : Second data driver specific argument */
    }
    } ;

    The other error you are getting is possibly related to the pool memory size. You need to set this in the same configuration file for the ARM side:

    STATIC LINKCFG_Pool LINKCFG_poolTable_00 [] =
    {
    {
    "SMAPOOL", /* NAME : Name of the pool */
    SHAREDENTRYID1, /* MEMENTRY : Memory entry ID (-1 if not needed) */
    (Uint32) POOLMEMORYSIZE, /* POOLSIZE : Size of the pool (-1 if not needed) */
    (Uint32) -1, /* IPSID : ID of the IPS used */
    (Uint32) -1, /* IPSEVENTNO : IPS Event number associated with POOL */
    POOLENTRYID, /* POOLMEMENTRY : Pool memory region section ID */
    0x0, /* ARGUMENT1 : First Pool-specific argument */
    0x0 /* ARGUMENT2 : Second Pool-specific argument */
    }
    } ;

    POOLMEMORYSIZE needs to match up with this line in dsplink-omap3530-base.tci, which defines the pool memory size for the DSP:

    POOLMEM.len = 0xD0000;

    After modifying the ARM-side configuration file CFG_OMAP3530_SHMEM.c, make sure you rebuild the kernel driver dsplinkk.ko and update it on your target filesystem. And of course, if you modify the .tci file you would need to rebuild the DSP side executable as well.

    See if this helps.

    -Vincent

     

     

  • Thank you very much Vincent for your prompt reply.

    Tomorrow morning I'll check immediately what you suggest to do (in Italy it's pretty late now...).

    On a side note, I read in the past days that if the memory sizes are increased (e.g. POOLMEMORYSIZE) the first address (RESETCTRLADDR if I recall correctly) must be lowered accordingly, so that the final address remains 8FFFFFFF. Can you confirm this?

    p.s. In my first post I wrote that I can exchange 16kB between ARM and DSP, but actually they are 14kB (16384)

  • Hi Filippo,

    The answer to your question is dependent on the amount of memory you actually have. I am not sure how much is at your disposal, but if the range beyond 0x8FFFFFFF is invalid or taken by something else in the system, you should avoid using that range, and one way to do that would be to move everything to a lower address range as you described -- assuming the lower range is available.

    If you find you truly need to do that, you would need to make sure both ARM and DSP agree on the ranges being used for the sections defined in CFG_OMAP3530_SHMEM.c and dsplink-omap3530-base.tci.

    Best regards,

    Vincent

  • Thanks again Vincent, I'll check soon.

    And again, forget the "p.s." yesterday I was too tired to do some math and confused kilos with powers of 2...

  • It worked!

    Modifying the MAXBUFSIZE field from 16384 to -1 now I can exchange up to about 210kB.

    Now I'll try to modify the POOLMEMORYSIZE too, to see if I can increase the buffer size further, since for my final application I need about 3-4MB.

    For now thank you very much, I'll let you know if I succed

    Filippo

  • Hi Vincent,

    Also your second suggestion worked!

    The modification of the POOLMEMORYSIZE in CFG_OMAP3530_SHMEM.c and POOLMEM.len in dsplink-omap3530-base.tci actually allowed me to pass 4MB which is more than enough for my final application.

    I tried to do this exact thing before but probably it didn't work since I hadn't modified the MAXBUFSIZE too.

    My only concern is that it seems that the amount of memory allocated for the pool (I enlarged the POOLMEMORYSIZE from 0xd0000 to 0x1000000 which is about 16MB) is larger than the actual memory I can use for the buffer (about 4MB). I'd appreciate if you could shed some light on this point so that I can use the memory in a more controlled way.

    By the way, now it works, so thanks, thanks again!

  • Hi Filippo,

    Good to hear you got it working.

    I am not sure if I understand your last question though. If 16MB is too large, you can set POOLMEMORYSIZE to 4MB. Are you not able to do that?

    Best regards,

    Vincent

  • Sorry Vincent, I didn't notice till now that you replied once more, and I thank you for that.

    I'll try to clarify my doubt: I'd expect to need to set the pool size to an amount that equals (or is slightly greater than) the amount of memory I need for my buffer. So, to write/read a buffer of 3-4MB I need to set the pool size to 0x01000000 which is 16MB. I found that pool size by means of trial and error, so maybe a little less will still work, but 0x00400000 is not enough.

    But apart from this issue (which is not so important since it seems not to be a problem to allocate that memory), I have encountered another problem running my computer vision algorithm on the DSP related to DSP MMU.

    By the way I'll open another thread for that since I consider this one pretty solved.

    Filippo