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

[DM816x] what DSKT2 & DMAN3 Configuration to use with codec's "alloc" function for dma buffer allocation on Netra EVM

Dominic D'Souza
Prodigy 110 points

Hi,

There appears to be something wrong in my setup of the DMAN3 and DSKT2 and the memory allocation configuration for my DMA buffer (see alloc code snippet) on the Netra EVM.

Using the Netra EVM, my configuration is as follows:

In the all_syslink.cfg file

var DSKT2 = xdc.useModule('ti.sdo.fc.dskt2.DSKT2');
DSKT2.DARAM0 = "INT_HEAP";
DSKT2.DARAM1 = "INT_HEAP";
DSKT2.DARAM2 = "INT_HEAP";
DSKT2.SARAM0 = "INT_HEAP";
DSKT2.SARAM1 = "INT_HEAP";
DSKT2.SARAM2 = "INT_HEAP";
DSKT2.ESDATA = "EXTALG_HEAP";
DSKT2.EPROG = "EXTALG_HEAP";
DSKT2.IPROG = "INT_HEAP";
DSKT2.DSKT2_HEAP = "EXT_HEAP";
//DSKT2.ALLOW_EXTERNAL_SCRATCH = false;
//DSKT2.SARAM_SCRATCH_SIZES[0] = 64 * 1024;  // 32k scratch for groupId 0
DSKT2.DARAM_SCRATCH_SIZES = [ 65536, 2048, 0,0,0,0,0, /* ... */ 0 ];
DSKT2.SARAM_SCRATCH_SIZES = [ 65536, 2048, 0,0,0,0,0, /* ... */ 0 ];

var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3');
DMAN3.heapInternal    = "INT_HEAP";
DMAN3.heapExternal    = "EXTALG_HEAP";
DMAN3.idma3Internal   = false;
DMAN3.scratchAllocFxn = "DSKT2_allocScratch";
DMAN3.scratchFreeFxn  = "DSKT2_freeScratch";
DMAN3.qdmaPaRamBase      = 0x09004000;DMAN3.maxPaRamEntries    = 512;
DMAN3.paRamBaseIndex     = 129;  // 1st EDMA3 PaRAM set available for DMAN3
DMAN3.numQdmaChannels    = 6;   // number of device's QDMA channels to use
DMAN3.qdmaChannels       = [2,3,4,5,6,7]; // choice of QDMA channels to use
DMAN3.numPaRamEntries    = 48;  // number of PaRAM sets exclusively used by DMAN
DMAN3.nullPaRamIndex     = 128;
DMAN3.numPaRamGroup[0]   = 48;  //number of PaRAM sets for scratch group 0
DMAN3.numTccGroup[0]     = 22;  //number of TCCs assigned to scratch group 0
DMAN3.tccAllocationMaskL = 0xFC00000F;   // bit mask indicating which TCCs 0..31to use
DMAN3.tccAllocationMaskH = 0xFF0F0000; // assign all TCCs 32..63 for DMAN

var RMAN = xdc.useModule('ti.sdo.fc.rman.RMAN');
RMAN.useDSKT2 = true;
RMAN.tableSize = 10;

Then In the codec's alloc function, the dma buffer is allocated as:
    memTab[6].size = DMA_BUFFER_TOTAL_SIZE;
    memTab[6].alignment = 128;
    memTab[6].space = IALG_EXTERNAL; //IALG_DARAM0; //IALG_SARAM;
    memTab[6].attrs = IALG_SCRATCH;

 

 

Previously, when the DMA was working on our DaVinci device, it used to have the following configuration:

In the codec's alloc function:

    memTab[6].size = DMA_BUFFER_TOTAL_SIZE;
    memTab[6].alignment = 128;
    memTab[6].space = IALG_DARAM0;
    memTab[6].attrs = IALG_SCRATCH;

In the codec's cfg file:

    var DSKT2 = xdc.useModule('ti.sdo.fc.dskt2.DSKT2');
    DSKT2.DARAM0     = "L1DSRAM";
    DSKT2.DARAM1     = "L1DSRAM";
    DSKT2.DARAM2     = "L1DSRAM";
    DSKT2.SARAM0     = "L1DSRAM";
    DSKT2.SARAM1     = "L1DSRAM";
    DSKT2.SARAM2     = "L1DSRAM";
    DSKT2.ESDATA     = "DDRALGHEAP";
    DSKT2.IPROG      = "L1DSRAM";
    DSKT2.EPROG      = "DDRALGHEAP";
    DSKT2.DSKT2_HEAP = "DDR";
    DSKT2.debug = false;
    DSKT2.DARAM_SCRATCH_SIZES = [ 65536, 2048, 0,0,0,0,0, /* ... */ 0 ];
    DSKT2.SARAM_SCRATCH_SIZES = [ 65536, 2048, 0,0,0,0,0, /* ... */ 0 ];

    var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3');
    DMAN3.heapInternal = "L1DSRAM";
    DMAN3.heapExternal = "DDRALGHEAP";
    DMAN3.paRamBaseIndex = 78;
    DMAN3.numQdmaChannels = 8;
    DMAN3.qdmaChannels = [0,1,2,3,4,5,6,7];
    DMAN3.numPaRamEntries = 48;
    DMAN3.numPaRamGroup[0] = 48;
    DMAN3.numTccGroup[0] = 8;
    DMAN3.tccAllocationMaskL = 0;
    DMAN3.tccAllocationMaskH = 0xffffffff;

    DMAN3.idma3Internal   = false;
    DMAN3.scratchAllocFxn = "DSKT2_allocScratch";
    DMAN3.scratchFreeFxn  = "DSKT2_freeScratch";

    DMAN3.debug = false;

  • 0
    TI__Expert 7415 points

    Where is the codec stuck ? I am interested in knowing the symptoms of the problem. 

    Looks like you changed the configuration to make all QDMA channels and TCCs 32 -63 available for use by DMAN3. Are you sure nothing else is  using these resources ? Are there drivers on the ARM-side that are using the DMA ? What resources are they using ? Any used resources need to be excluded from what you configure for use by DMAN3.

  • 0 in reply to Gunjan
    Prodigy 110 points

    The codec does not appear to be stuck. It is processing input frames now and does not halt anymore after i changed the DaVinci based configuration to use what was posted here http://e2e.ti.com/support/embedded/f/355/p/116610/415660.aspx.

    But the problem now is, one of the outputs of the codec is an image, that does not appear to be formatted properly. Rows of the image seem to be repeated. Hence that led me to believe that the problem could be either with the configuration or with the codec. I tried to find and change all instances of the #channels in our codec code from 8 to 6, but the configuration (.cfg files and alloc function) on the netra is the part i am having issues with.

    I was going by what was posted at http://e2e.ti.com/support/embedded/f/355/p/116610/415660.aspx

    where the channels are set to 6, i.e. [2,3,4,5,6,7] and the allocation masks were set to:

    DMAN3.tccAllocationMaskL = 0xFC00000F;   // bit mask indicating which TCCs 0..31to use
    DMAN3.tccAllocationMaskH = 0xFF0F0000; // assign all TCCs 32..63 for DMAN

    As far as i know, the only thing on the Cortex side is the example application app_remote.xv5T that is running. This application was created using the example provided in the 05_00_00_11/codec-engine_3_21_00_10/examples/ti/sdo/ce/examples/app directory.

  • 0 in reply to Dominic D'Souza
    TI__Expert 7415 points

    The post you refer to asks for suitable DMAN3 configuration in the  presence of a Linux driver on the ARM side that uses DMA resources. That is the reason configuration doesn't make all TCCs and QDMA channels available to DMAN3. Correct DMAN3 configuration depends on your use case, and other DMA users on your system.

  • 0 in reply to Gunjan
    Prodigy 110 points

    I am just trying to take what configuration was on our DaVinci device and get it to work on the Netra EVM, using the provided examples which i don't see as using the DMA. So as far as i know only our codec is using the DMA.  I don't know if any of the Linux drivers that come with the SDK's VS2 demo use the DMA resources.

  • 0 in reply to Dominic D'Souza
    TI__Expert 7415 points

    Configuration from the Davinci device will not work directly for Netra, some things like baseAddress etc will definitely need to be changed. I think the post does a good job of summarizing the DMAN3 parameters that will need to be configured.

    Your second question might be better answered by the SDK folks, I am not familar with the VS2 demo and/or specific codec requirements.

    In general, if the codec (rather DMAN3) is the only entity using the DMA, then you should be able to assign all possible resources to it (qdma channels, tccs params etc), since nothing needs to be partitioned off for use by the ARM. Since that didn't work for you, you could make the config changes one by one to find out the offending change, that might help you narrow it down.

  • 0 in reply to Gunjan
    Prodigy 110 points

    Thanks Gunjan.

    So then in that case, if the DMA is not used by anything else on the Cortex side and if i wanted to assign all possible resources to it, I could go with the following settings as very generic configuration. Do you seen issues with the following config?

        DMAN3.qdmaPaRamBase      = 0x09004000;
        DMAN3.maxPaRamEntries    = 512;

        DMAN3.paRamBaseIndex     = 129; // 1st EDMA3 PaRAM set available for DMAN3
        DMAN3.numQdmaChannels    = 8;   // number of device's QDMA channels to use
        DMAN3.qdmaChannels       = [0,1,2,3,4,5,6,7]; // choice of QDMA channels to use
        DMAN3.numPaRamEntries    = 48;  // number of PaRAM sets exclusively used by DMAN
        DMAN3.nullPaRamIndex     = 128;
        DMAN3.numPaRamGroup[0]   = 48;  //number of PaRAM sets for scratch group 0
        DMAN3.numTccGroup[0]     = 8;
        DMAN3.tccAllocationMaskL = 0;
        DMAN3.tccAllocationMaskH = 0xffffffff;

  • 0 in reply to Dominic D'Souza
    TI__Expert 7415 points

    I don't see any issues with that config. This should work just fine.... I suspected something on the ARM side, since you reported this kind of configuration not working for you.

  • 0 in reply to Gunjan
    Expert 2030 points

    Dominic,

    EDMA resources could still be in use by linux kernel drivers [Network/USB etc], even if user applications are not running. As for DMA not working properly, there seems to be L3 memory map mismatch between what DSP sees and what the EDMA controller sees when it comes to DSP's internal memory. Scratch buffers usually are allocated from internal memory..

     

    RV.

     

  • 0 in reply to RV
    Prodigy 110 points

    RV,

    Thankyou for the good info. Regarding the L3 memory map mismatch, i saw your discussion with and was wondering if he had replied to your query regarding which file to make the modifications to?

    Dominic

  • 0 in reply to Dominic D'Souza
    Expert 2030 points

    Not yet. I have raised this issue elsewhere.

    Feel free to comment on that post, if you are seeing issues as well.

     

    RV