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

RTOS/DRA71: RTOS-LINUX: IPU1 shared regions

Christian N
Expert 1285 points
Part Number: DRA71

Tool/software: TI-RTOS

Team

We are having some issues related with heap

[0][      8.901] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
[0][      8.901] [t=0xe1cd9b9f] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61
[0][    283.501] [t=0x0000001c:15aed3ed] xdc.runtime.Memory: ERROR: line 52: out of memory: heap=0x80062a08, size=72
[0][    283.501] xdc.runtime.Memory: line 52: out of memory: heap=0x80062a08, size=72
[0][    283.501] [t=0x0000001c:15b171ef] ti.sdo.ipc.MessageQ: ERROR: line 503: assertion failure: A_invalidMsg: Invalid message
[0][    283.502] ti.sdo.ipc.MessageQ: line 503: assertion failure: A_invalidMsg: Invalid message
[0][    283.502] xdc.runtime.Error.raise: terminating execution

IPU1 (RTOS) configured memory map

	MEMORY CONFIGURATION
	
	         name            origin    length      used     unused   attr    fill
	----------------------  --------  ---------  --------  --------  ----  --------
	  L2_ROM                00000000   00004000  000005d0  00003a30  RWIX
	  EXT_CODE              00004000   000fc000  00022eb9  000d9147  RW X
	  L2_RAM                20000000   00010000  00000000  00010000  RWIX
	  OCMC_RAM1             40300000   00080000  00000000  00080000  RWIX
	  OCMC_RAM2             40400000   00100000  00000000  00100000  RWIX
	  OCMC_RAM3             40500000   00100000  00000000  00100000  RWIX
	  EXT_DATA              80000000   00200000  00063246  0019cdba  RW  
	  EXT_HEAP              80200000   00300000  00000000  00300000  RW  
	  TRACE_BUF             9f000000   00060000  00008000  00058000  RW  
	  EXC_DATA              9f060000   00010000  00000200  0000fe00  RW  
	  PM_DATA               9f070000   00020000  00000000  00020000  RW X

A15 (Linux) device tree reserved memory

   reserved_mem: reserved-memory {
      #address-cells = <2>;
      #size-cells = <2>;
      ranges;

      ipu1_cma_pool: ipu1_cma@9d000000 {
         compatible = "shared-dma-pool";
         reg = <0x0 0x9d000000 0x0 0x2000000>;
         reusable;
         status = "okay";
      };

      latea_pagetbl: late_pgtbl@afc00000 {
         reg = <0x0 0xafc00000 0x0 0x200000>;
         no-map;
         status = "okay";
      };
   };

Should EXT_xxx, TRACE_BUF, EXC_DATA, PM_DATA regions, be defined in device tree?

These should be defined as shared-dma-pool and reusable?

Regards

  • 0
    TI__Expert 3640 points
    Hi Christian,

    The addresses listed in the memory map are IPU virtual addresses. The addresses listed in the reserved memory in the dt file are physical addresses. The IPU virtual addresses are not listed in the dt file. However, the virtual addresses for these sections in the memory map do need to be associated with a corresponding physical address. This association is done in the remote core resource table.

    You can see packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h in the IPC3.x code as an example resource table. You can check your resource table to make sure that the virtual addresses for these sections are represented in the resource table. (Note that if you are using the default ipu1_cma_pool dt entry and the default IPC3.x IPU1 resource table, this is already taken care of).

    For example, EXT_DATA and EXT_HEAP sections starting at virtual address 0x80000000:

    EXT_DATA 80000000 00200000 00063246 0019cdba RW
    EXT_HEAP 80200000 00300000 00000000 00300000 RW

    Can be found in the example resource table here at line 245:


    {
    TYPE_CARVEOUT,
    IPU_MEM_DATA, 0,
    IPU_MEM_DATA_SIZE, 0, 0, "IPU_MEM_DATA",
    },

    Where:

    #define IPU_MEM_DATA 0x80000000
    #define IPU_MEM_DATA_SIZE (SZ_1M * 5)

    Since this resource table entry is a "TYPE_CARVEOUT", the physical address will get allocated during loading of the remote core from the ipu1_cma_pool defined in the dt file (and in the u-boot code, if doing early loading). This is why the physical address in this resource table entry is listed as 0.

    Information about the resource table can be found here processors.wiki.ti.com/.../IPC_Resource_customTable and here www.kernel.org/.../remoteproc.txt.

    Regarding the heap allocation failure, I see you also have a thread here (e2e.ti.com/.../722042) covering debugging of that. Please let us know if there are additional questions related to that error.

    Thanks,
    Angela
  • 0 in reply to Angela Stegmaier
    Expert 1285 points

    Hi Angela

     

    Taken the files that you showed as example, notice that

     

    #define TRACEBUFADDR (UInt32)&ti_trace_SysMin_Module_State_0_outbuf__A
...
    {
        TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:sysm3",
    },

    and in _linkInfo.xml

          <symbol id="sm-2b2e">
         <name>ti_trace_SysMin_Module_State_0_outbuf__A</name>
         <value>0x9f000000</value>
         <object_component_ref idref="oc-20e4"/>
      </symbol

    from CCS Memory Browser 0x9F000000 match with  ti_trace_SysMin_Module_State_0_outbuf__A symbol, and there are the traces

    from processors.wiki.ti.com/.../Linux_IPC_on_AM57xx and https://www.kernel.org/doc/Documentation/remoteproc.txt I understand that it is a trace memory type

    1-0x9F000000 is virtual address?

    2-IPU is starting before Linux (U-boot puts it to work), so virtual<->physical tables should be there. How does Linux know where is the phy trace (heap, pm, other than PHYS_MEM_IPC_VRING where code/data should be) address, to avoid overwriting?

    Regards

  • 0 in reply to Christian N
    TI__Expert 3640 points

    Hi Christian,

    Christian N said:

    1-0x9F000000 is virtual address?

    Yes, this is a virtual address

    Christian N said:

    2-IPU is starting before Linux (U-boot puts it to work), so virtual<->physical tables should be there. How does Linux know where is the phy trace (heap, pm, other than PHYS_MEM_IPC_VRING where code/data should be) address, to avoid overwriting?

    This is taken care of by updating Linux kernel for "late-attach". When late-attach flags are set, the kernel drivers bypass firmware loading and MMU programming (since it is expected to already be done) and make only the allocations so that it has the correct physical addresses for the TYPE_CARVEOUT regions. The same CMA base address is used in u-boot and Linux kernel, and both use allocators that have the same allocation logic, so that when u-boot or Linux kernel allocate from the CMA region, they get the same addresses. 

    Thanks,

    Angela

  • 0 in reply to Angela Stegmaier
    Expert 1285 points

    Hi Angela

    As far I know, sections other than code/data are not in DeviceTree.

    At kernel boot time it parses DT and from it takes parameters for drivers (like remoteproc). Sections like heap are inside ipu firmware header, but it is in vendor file system, which one is mounted later.

    In this scenario kernel doesn't know that memory sections (other than code/date) are being used by ipu.

    -Is kernel taken from U-boot any memory parameter to avoid overwriting?

    -Where is kernel taken section, other than code/data, address already in use?

    Regards

  • 0 in reply to Christian N
    TI__Expert 3640 points
    Hi Christian,

    When setting the "late-attach" flags in dt, remoteproc driver will still get the resource table from the firmware in the filesystem (dra7-ipu1-fw.xem4) and parse it. This firmware should be the same firmware that is early loaded by u-boot. Remoteproc will perform allocations from the CMA pool for the VRINGS and all TYPE_CARVEOUTS. After doing these allocations, the remoteproc driver then knows the associated physical address for each entry in the resource table. And since this memory has now been allocated by remoteproc from the CMA pool, it is no longer available for use by Linux.

    Kernel doesn't take any parameter from u-boot. Only requirement is that CMA base address matches between u-boot and linux kernel dt file to make sure that the allocations match.

    Also, note that the trace buffer VA 0x9f000000 falls within this entry in the resource table (so does EXC_DATA and PM_DATA):

    {
    TYPE_CARVEOUT,
    IPU_MEM_IPC_DATA, 0,
    IPU_MEM_IPC_DATA_SIZE, 0, 0, "IPU_MEM_IPC_DATA",
    },

    where
    #define IPU_MEM_IPC_DATA 0x9F000000
    #define IPU_MEM_IPC_DATA_SIZE SZ_1M

    This entry:

    {
    TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:sysm3",
    },

    Is informational so that the kernel knows where the trace buffer is located. By getting the virtual address, it can look up the physical address using the resource table.

    Thanks,
    Angela