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 Trace Buffer Size and Placement

Part Number: AM5728

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

I have a question related to ipc_3_43_02_04/packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h:

    {

        TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:dsp",

    },

Questions:

  1. What implication does TYPE_TRACE have on the allocation, i.e. does this get pulled from the DSP's CMA region, or does it come from somewhere else?  If somewhere else, where?
  2. The size specified here is 32KB.  However, in  ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld we define TRACE_BUF as having size 0x60000 (384 KB).  In the corresponding map file I see that 0x8004 of the 0x60000 bytes are actually in use.  So it appears we have allocated more memory than is actually being mapped to the MMU.  This seems like a bug unless I've misunderstood something.  We either need to shrink the TRACE_BUF in config.bld or increase the size in the resource table.

  • Hi Brad,

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

    1. TYPE_TRACE is not pulled from CMA region. It points to &ti_trace_SysMin_Module_State_0_outbuf__A.

    2. .tracebuf in DSP map file includes extra ti_trace_SysMin_Module_State_0_readidx__A at 0x9f008000. Yes,  TRACE_BUF defined in config.bld to 0x60000 (384 KB) appears to be too big and can be shrunk.

    Regards,

    Garrett

  • Hi Brad,

    TYPE_TRACE by itself doesn't cause any allocations, but it definitely needs the corresponding backing memory to be defined. This entry is used by the BIOS-side images to provide information about the trace buffer to the kernel-side driver. The TRACEBUFADDR is the remote processor's device address for the trace buffer along with its size (also includes the some write pointer). The remoteproc trace buffer is a circular buffer, so traces will be overwritten after the wrap-around, so the size for a trace buffer is a factor of how many traces you want to see at one go.

    The trace buffer can either be in L2 RAM or DDR. Placing it in L2 RAM is usually of no benefit, as you will be reducing the L2 RAM for your usecases, and this has no allocation involved (You need to be careful with how you partition on the L2 RAM on BIOS-side). When it is placed in DDR, there is another RSC_CARVEOUT entry that will result in an allocation and mapping into IOMMU and provides the backing memory for traces.

    If you look at packages/ti/ipc/tests/package.bld, you will see a TRACE_BUF region defined for the linker in the externalMemory Map, with the following line
    Program.sectMap[".tracebuf"] = "TRACE_BUF";
    added to a .cfg file (ti/ipc/tests/[Dsp_vayu.cfg/Ipu1Smp.cfg/Ipu2Smp.cfg].

    The resource table can combine multiple linker regions into a single RSC_CARVEOUT entry. This is done to optimize the MMU Page Table Entry (PTE) - create larger PTEs where possible so as to reduce the TLB misses in the MMU. In the case of above resource table file you are referring, the DSP_MEM_IPC_DATA RSC_CARVEOUT entry does the allocation needed by TRACE_BUF, EXC_DATA, PM_DATA linker regions defined in packages/ti/ipc/tests/package.bld. The TRACE_BUF region has a size of 0x6000, so you can choose your trace buffer to be any size within that limit.

    Just to clarify a bit more, the RSC_CARVEOUTs are allocated on AM57xx platforms using the corresponding device's CMA pool (defined and linked to device in DTS file). The trace buffer size itself is controlled through the SysMin.bufSize configuration property (See packages/ti/ipc/tests/IpcCommon_vayu.cfg.xs).