• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 102 subscribers
  • Views 3694 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

EDMA3 on AM5728 RTOS DSP

Christopher Peters
Genius 3370 points

Hopefully a simple question....

We are using PCIe on both DSP cores x1 lane each.  I plan to use EDMA3 with the PCIe.

To initialize the EDMA3 driver you call edma3init(uint32_t edma3Id, EDMA3_DRV_Result *errorCode) as provided in

c:\ti\edma3_lld_02_12_01_22\packages\ti\sdo\edma3\drv\sample\src\sample_init.c

Now, the parameter edma3Id is the instance and I guess I can pick any number, but of course 0 seems like what you'd pick. 

What I am trying to figure out is this per DSP core or per SoC.  So, if each DSP core uses edma3Id = 0 will they in effect be trying to use the same underlying hardware?  Do I need to use a different instance per core?  The ARM will also be running Linux, so I guess we don't want the DSP to conflict with it either, so similar question there. 

  • 0
    TI__Guru**** 393215 points
    I will forward this to the RTOS team.
  • 0 in reply to Biser Gatchev-XID
    Genius 3370 points
    Could you ping the RTOS team again please?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru*** 125430 points
    I'm not from the RTOS team, but I wanted to make a comment on the hardware which might potentially provide some insight into the software. There are a total of 3 EDMAs in the device: 1 per DSP subsystem as well as an SoC-wide EDMA.
  • 0 in reply to Brad Griffis
    Genius 3370 points
    Thanks Brad. I was just reading about that in the TRM the other day. I guess I am not clear when you setup an EDMA instance how it knows which EDMA to use. Do the DSP's only use their dedicated EDMA and the ARM uses only the SoC EDMA? That might make sense to me that it would work that way. BTW, I don't need any DMA (at least not yet) between the DSPs or between the DSPs and the ARMs. Just between DSP/PCIe pairs.
  • 0 in reply to Christopher Peters
    TI__Guru**** 393215 points
    Cristopher,

    Just to let you know that this has reached the RTOS team, but the person who can support this query is currently out of office. He will be back next week.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    Ping me on this thread if you don't get a response by Tuesday.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru*** 125430 points
    I took a quick look at this. In particular I'm looking at the following file:

    edma3_lld_02_12_01_22\packages\ti\sdo\edma3\rm\src\configs\edma3_tda2xx_cfg.c

    I can see three instances defined. There are also build labels to conditionally configure various addresses depending on which core you're building for. EDMA3 Instance #0 uses base address 0x43300000 which corresponds to the "global" or "SoC" EDMA. That instance should be used for A15. That same hardware also gets used by the M4's, but since the M4's have a different "view" of the SoC memory map the #defines cause that to be 0x63300000.

    EDMA3 Instance #1 uses base address 0x01D10000. If you look at the DSP Memory Map in Chapter 2 you'll notice that's considered a "local resource". So in other words, for each DSP core you should choose "Instance 1" but those will in fact be unique hardware for each core (i.e. it is local to each DSP subsystem). So to answer your original question, from the DSPs you should be using "1" for the instance...
  • 0 in reply to Brad Griffis
    Genius 3370 points
    Thanks Brad I think that explains it well. It would be nice if the tda2xx_cfg.c file included a defines like:

    #define EDMA3_SOC_INST 0
    #define EDMA3_DSP_INST 1
    #define WHATEVER_INST 2

    I was a little surprised that there was no edma3_am572x_cfg.c, but somehow a while back I figured out that tda2xx was the correct one.
  • 0 in reply to Christopher Peters
    Intellectual 420 points

    Please note this is a serious documentation and example issue that just caused me multiple days of time. The provided SPI DMA PDK DSP driver specifies 0 for edma3 instance and will trip a Linux mmu exception (and reset and reload the DSP) if you use the provided example code in a hetrogenous system -- the instance 0 registers 0x4330xxxx are not mapped into the address space and the code will die on the init call.  Same is true for the edma3 example test code which loops through all the instances! - the first pass is 0 and will die on the edma3init call. Here is the edma3init call in the example code for the SPI DMA code:

    /**

    * \brief Function to initialize the edma driver and get the handle to the

    * edma driver;

    */

    static EDMA3_RM_Handle MCSPIApp_edmaInit(void)

    {

    EDMA3_DRV_Result edmaResult = EDMA3_DRV_E_INVALID_PARAM;

    EDMA3_RM_Handle gEdmaHandle = NULL;

    uint32_t edma3Id = 0; // on DSP must be 1 or you will get a MMU exception on the Linux (ARMA15) side !

    gEdmaHandle = (EDMA3_RM_Handle)edma3init(edma3Id, &edmaResult);

    if (edmaResult != EDMA3_DRV_SOK)

    {

    /* Report EDMA Error */

    System_printf("\nEDMA driver initialization FAIL\n");

    gEdmaHandle = NULL;

    }

    else

    {

    System_printf("\nEDMA driver initialization PASS.\n");

    }

    return(gEdmaHandle);

    }

    This issue is particularly nasty since when the error hits, the Linux remoteproc will destroy all the evidence!

    A quick grep shows this to be an issue in (at least)

    pdk_am57xx_1_0_2/packages/ti/drv/spi/test/src/main_mcspi_dma_test.c

    pdk_am57xx_1_0_2/packages/ti/drv/uart/test/src/main_dma_test.c

    setting the edma3Id to 1 will "fix" the problem.

    As noted the edma3 test code for the DSP also loops through all the instances but will crash on instance 0

    Please for the sanity of others and respect for their time, update the example code to document this.

    It would have ALSO helped if the edma3 documentation made some direct mention of this

  • 0 in reply to Bill Derby
    TI__Guru*** 125430 points

    Note that there is nothing fundamentally wrong with using the System EDMA.  Our testing was done in isolation, i.e. nothing running on ARM, so this issue is simply an ARM+DSP coexistence issue.  That said, I agree that this could be easily avoided by having the DSP use its own local EDMA resources.  I have discussed the issue with the RTOS team and they have filed an enhancement to add an #ifdef or similar to choose the local EDMA for DSP builds.