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.

RTOS/AM5716: EDMA memory issue

Part Number: AM5716


Tool/software: TI-RTOS

Hello,

My DSP application on DSP core use SoC EDMA to transfer data from ping pong buffer to/from McASP. and DSP memory is give by Linux , and it is from CMA pool defined in resources table. so the buffer address is the virtual address . My tone generator produces tone sample and put in this buffer. However, when EDMA is configured the address of buffer give to EDMA is virtual address, so EDMA did not read/write data from/to the physical address.

I try to allocated a memory outside the CMA pool, but Linux failed to load DSP, the error message is " bad address at xxxxxxxxxxxxx"

Is there any solution for this case?

Thanks in advance!

Ron

  • The RTOS team have been notified. They will respond here.
  • Hi,

    Is that correct understanding that:
    - You have a buffer allocated by Linux, which is a virtual address
    - There is data come in to this buffer. Is that correct you have a Linux driver for a peripheral (may be MCASP)? and the driver writes the data into this buffer?
    - You want to use the DSP to move this data to some another locations? But DSP don't know the physical address? How the DSP knows the data come in? MCASP interrupt DSP? Can you use the EDMA in Linux (A53) to move the data?
    - I don't understand if you have a Linux driver for MCASP to Rx data AND also have a DSP driver for MCASP for interrupt?

    Can you describe the data IN/OUT path?

    Regards, Eric
  • Hi Eric,

    sorry for reply late since I am just back.

    In my DSP application need to send/receive audio to/from McASP1, so I allocate a Ping Pong buffer from the memory assigned to DSP by Linux . since the memory is from CMA pool, all the address my DSP application see is virtual address. when DSP init code to configure EDMA, the source/destination address (ping pone buffer) is  virtual address. the virtual address used by DSP core is mapped to physical address, however, EDMA did not map, so DSP application and EDMA  actually read/write data to differnt memory location.  I tried to allocate my ping pone buffer from a memory not from CMA pool, so there is no mapping applied, but linux knernel failed to copy program segment into to this memory when loading up DSP binary. this my problem.

    Thanks,

    Ron

  • Ron,

    I checked with the Linux team, there is DTS file to define the CMA pool starting address and length. It is physical address, why you found the address assigned by Linux is virtual address? I thought virtual address is used by Linux kernel, but address assigned to DSP is physical. Can you clarify?

    Regards, Eric
  • Hi Eric,

    Maybe, I am confused which one is virtual, and which one physical.

    attached is my DTS, linker.cmd, and rsc_table_dsp.h, map file. 

    As you can see that in the resource table, the DSP_MEM_DATAis mapped to virtual address. if I declare an buffer, say, int buffer[4], and I can see the address of this buffer is in DSP_MEM_DATA, and the address of thei buffer is give to EDMA as sources/destination address.   when my  DSP driver read/write in this buffer, EDMA did not transfer the same data unless the buffer is not in any memeroy from CMA.

    {
    TYPE_CARVEOUT,
    DSP_MEM_DATA, 0,
    DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
    },

    thanks,

    Ron2630.linker.rarAIM_G3_DSP.rarrsc_table_dsp.rar7776.am571x-aim.rar

  • Hi, Ron,

    Your dts file doesn't have cma nodes. Even the dtsi file included in your evm dts file doesn't have any cma info. So, I don't know how your cma is defined in Linux. Assuming you have the same reserved memory as in TI's am571x-idk.dts file, DSP1 CMA is 64MB starting at 0x99000000. If I understand your resource table correctly, the DMA area is at DSP_MEM_DATA which is 0x95100000. It is not in the reserved area for dsp1_cma. Please try to match up with Linux and see if it works for you.

    Rex
  • Hi Eric,

    I am so sorry, I sent you wrong dts file. attached is the right one.

    best regards,

    Ron5187.am571x-aim-dts.rar

  • Hi, Ron,

    The cma reserved area for dsp is the same as TI default, so the statement in the previous post stays. Please check your DMA area to be sure it is in the reserved area.

    Rex
  • Hi Rex,

    thanks for qick response!

    I am the first time to use resources table  in DSP, and I have read some article of resouces table, but  I am still confused by virtual and physical address define . let me repeat my question.

    following are the my part of setting in in linker.cmd, resources table, and dts file. for example,   EXT_DATA is locate at 0x95100000~0x95200000 in my cmd file, and in resource table, #define DSP_MEM_DATA            0x95100000 is define as virtual address, and mapped to physical address by following setting in resource table:

    {
    TYPE_CARVEOUT,
    DSP_MEM_DATA, 0,
    DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
    },

    and  reg = <0x0 0x99000000 0x0 0x4000000>; is reserved as CMA pool in dts file.  my understanding is that 0x95100000~0x95200000 is virtuall address and mapped to physical address 0x99000000 0x0 0x4000000 , is my understanding correct?

    I checked my DSP map file, and I see all of my globla variables, buffer, etc are allocated in EXT_DATA is locate at 0x95100000~0x95200000

    ----------- linker cmd----------------------------

    MEMORY

    {

     L2SRAM (RWX)    : org = 0x800000,   len = 0x40000

     OCMC_RAM1 (RWX) : org = 0x40300000, len = 0x80000

     OCMC_RAM2 (RWX) : org = 0x40400000, len = 0x100000

     OCMC_RAM3 (RWX) : org = 0x40500000, len = 0x100000

     EXT_CODE (RWX)  : org = 0x95000000, len = 0x100000

     EXT_DATA (RW)   : org = 0x95100000, len = 0x100000

     EXT_HEAP (RW)   : org = 0x95200000, len = 0x300000

     EXC_DATA (RW)   : org = 0x9f060000, len = 0x10000

     PM_DATA (RWX)   : org = 0x9f070000, len = 0x20000

     DSP_DATA (RW)   : org = 0x94300000, len = 0x10000

    }

    -------------------- setting in resouce  table ---------------------------

    #define DSP_MEM_TEXT            0x95000000

    /* Co-locate alongside TILER region for easier flushing */

    #define DSP_MEM_IOBUFS          0x80000000

    #define DSP_MEM_DATA            0x95100000

    #define DSP_MEM_HEAP            0x95200000

    //#define DSP_NON_CACHE_DATA      0x96000000

    #define DSP_MEM_IPC_DATA        0x9F000000

    #define DSP_MEM_IPC_VRING       0x99000000

    #define DSP_MEM_RPMSG_VRING0    0x99000000

    #define DSP_MEM_RPMSG_VRING1    0x99004000

    #define DSP_MEM_VRING_BUFS0     0x99040000

    #define DSP_MEM_VRING_BUFS1     0x99080000

    #define DSP_NONCACHE_DATA       0x94300000

    #define DSP_MEM_IPC_VRING_SIZE  SZ_1M

    #define DSP_MEM_IPC_DATA_SIZE   SZ_1M

    #define DSP_MEM_TEXT_SIZE       SZ_1M

    #define DSP_MEM_DATA_SIZE       SZ_1M

    #define DSP_MEM_HEAP_SIZE       (SZ_1M * 3)

    #define DSP_MEM_IOBUFS_SIZE     (SZ_1M * 4)

    // by ron

    #define L3_DSP1_SYSTEM_SIZE     (SZ_1M)

    #define L3_EDMA_TPCC_SIZE       (SZ_1M)

    #define L3_EDMA_TC0_SIZE        (SZ_1M)

    #define L3_EDMA_TC1_SIZE        (SZ_1M)

    #define L3_MCASP1_CFG_SIZE      (SZ_1M*4)

    #define L3_MCASP2_CFG_SIZE      (SZ_1M*4)

    #define DSP_NONCACHE_DATA_SIZE  SZ_1M

    //-----------------

    /* NOTE: Make sure this matches what is configured in the linux device tree */

    #define DSP_CMEM_IOBUFS 0x94000000

    #define PHYS_CMEM_IOBUFS 0x94000000

    #define DSP_CMEM_IOBUFS_SIZE (SZ_1M * 4)

    #define DSP_CMEM_AUDIOBUFS  0x94400000

    #define PHYS_CMEM_AUDIOBUFS 0x94400000

    #define DSP_CMEM_AUDIOBUFS_SIZE (SZ_1M)

    /*

    * Assign fixed RAM addresses to facilitate a fixed MMU table.

    */

    #define VAYU_DSP_1

    /* See CMA BASE addresses in Linux side: arch/arm/mach-omap2/remoteproc.c */

    #if defined (VAYU_DSP_1)

    #define PHYS_MEM_IPC_VRING      0x99000000

    #elif defined (VAYU_DSP_2)

    #define PHYS_MEM_IPC_VRING      0x9F000000

    #endif

    /* Need to be identical to that of IPU */

    #define PHYS_MEM_IOBUFS         0xBA300000

    /*

    * Sizes of the virtqueues (expressed in number of buffers supported,

    * and must be power of 2)

    {
    TYPE_CARVEOUT,
    DSP_MEM_DATA, 0,
    DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
    },

    ----------------------- dts -------------------------------------

    {

           model = "TI AM5716 AIM";

           compatible = "ti,am5716-aim", "ti,am5716", "ti,dra7";

           aliases {

           };

           memory@80000000 {

                   device_type = "memory";

                   reg = <0x0 0x80000000 0x0 0x40000000>;

           };

           reserved-memory {

                   #address-cells = <2>;

                   #size-cells = <2>;

                   ranges;

                   ipu2_cma_pool: ipu2_cma@95800000 {

                           compatible = "shared-dma-pool";

                           reg = <0x0 0x95800000 0x0 0x3800000>;

                           reusable;

                           status = "okay";

                   };

                   dsp1_cma_pool: dsp1_cma@99000000 {

                           compatible = "shared-dma-pool";

                           reg = <0x0 0x99000000 0x0 0x4000000>;

                           reusable;

                           status = "okay";

                   };

                   ipu1_cma_pool: ipu1_cma@9d000000 {

                           compatible = "shared-dma-pool";

                           reg = <0x0 0x9d000000 0x0 0x2000000>;

                           reusable;

                           status = "okay";

                   };

           };

    };

    /*

    thanks,

    Ron

  • Hi, Rong,

    Could you provide the document link from which you get the info that the resource table is mapping vritual to physical addresses?

    I am not a DSP person, but my understanding of the linker.cmd is to define DSP memory area/usage and their location. The way I interpret the following definition :

    {
    TYPE_CARVEOUT,
    DSP_MEM_DATA, 0,
    DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
    },

    is the area labelled as "DSP_MEM_DATA" at 0x95100000 (as in #define ) of size 1M is type of CARVEOUT (it means from carved out area, i.e. CMA pool) . If DSP_MEM_DATA(0x95100000) is the virtual address, I don't see which physical address it is mapped to in above definition. Usually, if it is a mapping, there should be a 1-to-1 correspondence which I don't see the relation exists.

    I am not sure if you have read the resource table document in processors.wiki.ti.com/.../IPC_Resource_customTable. If you haven't, you may find useful info in it.

    Rex
  • Hi Rex,

    yes, I read this article, and I see the following sentences:

    " The 2nd-4th entries are:

        {
            TYPE_CARVEOUT,
            IPU_MEM_TEXT, 0,
            IPU_MEM_TEXT_SIZE, 0, 0, "IPU_MEM_TEXT",
        },
        {
            TYPE_CARVEOUT,
            IPU_MEM_DATA, 0,
            IPU_MEM_DATA_SIZE, 0, 0, "IPU_MEM_DATA",
        },
        {
            TYPE_CARVEOUT,
            IPU_MEM_IPC_DATA, 0,
            IPU_MEM_IPC_DATA_SIZE, 0, 0, "IPU_MEM_IPC_DATA",
        },

    These carveouts tell remoteproc to allocate memory from its CMA area and map the allocated physical address to the virtual address specified in the carveout (the 1st field after TYPE_CARVEOUT), in the IPU’s MMU (“iommu” in Linux kernel parlance). These are for the ELF sections that are placed (mapped) in those virtual address. "

    In my case, the first field after TYPE_CARVEOUT is DSP_MEM_DATA which is defined as #define DSP_MEM_DATA 0x95100000  in our custom resource table(rsc_table_dsp.h).  according to the sentence in red, it is virtual address.  Is it right?

    thanks,

    Ron

     

  • Link the other duplicate thread here: e2e.ti.com/.../692915
  • Hi Rex,

    the domument says:

    "These carveouts tell remoteproc to allocate memory from its CMA area and map the allocated physical address to the virtual address specified in the carveout (the 1st field after TYPE_CARVEOUT), in the IPU’s MMU (“iommu” in Linux kernel parlance). These are for the ELF sections that are placed (mapped) in those virtual address."

    in our dts file, the cma pool for dsp1 is at @99000000,  so DSP_MEM_DATA(0x95100000) is mapped to 0x99000000?

    dsp1_cma_pool: dsp1_cma@99000000 {
    compatible = "shared-dma-pool";
    reg = <0x0 0x99000000 0x0 0x4000000>;
    reusable;
    status = "okay";
    };

    for your reference, my dsp.cfg file is attached as well.

    regards,

    RonDspcfg.rar

  • Rong,

    I just had a discussion on this with several people including the DSP engineer. Once confirmed, we may want you to try changing the configuration to see if it works for you. Thank you for your patience.

    Rex
  • Hi, Rong,

    Sorry, it took longer than I expected to get back to you. The EDMA access should also go through MMU. That is, virtual address applies to EDMA as well. From your post, it seems to me that the McASP accesses the buffer through virtual address, but the EDMA tries to read/write data using physical address? If that is the case, could you try EDMA using virtual address as well? If that was what you have been doing, then it will be an issue in MMU translation on the EDMA case, and we need to look at it further.

    Then, I'll suggest the workaround to try not defining the EDMA area from the CARVEOUT area, but using TYPE_DEVMEM which is direct mapping. There shouldn't be any confusion, and no MMU translation involved. The only thing is that you need to be sure the area is reserved in LInux dts file in reserved-memory node. You can take a look at big data example under linux-sdk/example-applications/big-data-ipc-demo to see how DEVMEM memory defined in resource table.

    Rex