• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1572 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.

AM5728: IPC Memory Map MEM_IOBUFS

Brad Griffis
Guru*** 125430 points

Part Number: AM5728

AM5728 EVM
Linux on ARM
TI-RTOS on 66x
Proc SDK Linux and RTOS 3.01

From the resource table in ipc_3_43_02_04/packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h we have this mapping:

{
TYPE_DEVMEM,
DSP_MEM_IOBUFS, PHYS_MEM_IOBUFS,
DSP_MEM_IOBUFS_SIZE, 0, 0, "DSP_MEM_IOBUFS",
},

#define DSP_MEM_IOBUFS 0x80000000
#define PHYS_MEM_IOBUFS 0xBA300000
#define DSP_MEM_IOBUFS_SIZE (SZ_1M * 90)

Questions on this:

  1. Why is it TYPE_DEVMEM?  Most of the other usages of TYPE_DEVMEM are for defining a mapping to peripheral space.
  2. Related to #1, since this is not a "carveout" then I expect it is not being allocated from the associated CMA.  That said, where is this coming from?  I don't see a reference to 0xBA300000 anywhere in Linux, so I don't understand how this "plays nice" with Linux.
  3. Any reason why it's 90MB?  Why not 64MB or 96MB (to be a multiple of 16MB for supersection mapping)?

  • 0
    TI__Guru**** 393215 points
    Hi Brad,

    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 43296 points

    Hi Brad,

    1. TYPE_DEVMEM defined in IPC maps to RSC_DEVMEM in Linux remoteProc driver include/linux/remoteproc.h:

    /**

    * enum fw_resource_type - types of resource entries

    *

    * @RSC_CARVEOUT:   request for allocation of a physically contiguous

    *                  memory region.

    * @RSC_DEVMEM:     request to iommu_map a memory-based peripheral.

    .......

    */

    enum fw_resource_type {

           RSC_CARVEOUT    = 0,

           RSC_DEVMEM      = 1,

           RSC_TRACE       = 2,

           RSC_VDEV        = 3,

           RSC_INTMEM      = 4,

           RSC_CUSTOM      = 5,

           RSC_LAST        = 6,

    };

    Yes, it's typically for defining a mapping to peripheral space.

    2. Similar to other mappings to peripheral space, 0xBA300000 is a physical address space that is assumed to be I/O space in Linux reserved for DSP I/O buffer.

    3. No specific reason why it's 90MB. Both 1MB or 16MB are configured in MMU first level translation table.


    Regards,

    Garrett

  • 0 in reply to Garrett Ding
    TI__Guru*** 125430 points

    Garrett Ding said:
    2. Similar to other mappings to peripheral space, 0xBA300000 is a physical address space that is assumed to be I/O space in Linux reserved for DSP I/O buffer.

    What is meant by "I/O space in Linux reserved for DSP I/O buffer"? I thought that purpose was filled by CMA and/or CMEM.  This seems to be "something else", but it's not clear what...  Since there's no carveout (i.e. just an MMU mapping), how do we avoid Linux from trampling on this memory  It doesn't look to me like this is actually being used, and furthermore, it looks like if the DSP started writing to this space that you would likely crash the ARM.  Am I missing something?

  • 0 in reply to Brad Griffis
    TI__Guru*** 125395 points

    This particular entry needs to be removed from the DRA7xx/AM57xx resource tables. I believe it was copied over from OMAP4/OMAP5 resource tables where it served as mapping a single ION carveout into each of the remote processors.

    The current remoteproc infrastructure lacks runtime mapping of buffer regions. So any carveouts like CMEM carveouts reused the TYPE_DEVMEM for mapping the carveout into the MMU. Once the remoteproc infrastructure is enhanced with runtime mapping, this overloading of TYPE_DEVMEM for carveouts can be removed and replaced with a mapping of only the required buffers on the Linux side.