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.

J721EXCPXEVM: J721S2XSOMXEVM: IPC mcu2_0 <-> mpu1_0 Data Exchange via Shared Memory

Part Number: J721EXCPXEVM

Tool/software:

Hi,

I am working on the IPC between uC and uP on J721S2; I could exchange small data between mcu2_0 and mpu1_0, but I would like to use a DDR region as a Shared Memory between these cores to be able to exchange large amounts of data and pass the pointer to the data region or something to exchange say 100MB data.

I believe I could use the reserved memory regions of the particular core from the dts as the shared memory, right?
If yes, how does this work with the VRING Buffers, as I assume these are also part of this reserved memory region.

Could you kindly provide some information related to the Shared Memory setup?

Setup:

  • Linux SDK 9.2
  • RTOS/PDK SDK 9.2
  • rpmsg_char (Linux) <-> ipc echo (Baremetal - pdk - MAIN R5F)

Thank you,
Moses

  • Hello,

    Thank you for posting your question. I have assigned your question to the appropriate engineer, but do note that they are out of office this week. Please expect a response from them next week regarding your issue. 

    Best,

    Asha

  • Hello Moses,

    Sorry for the delay, i was out of office.

    I could exchange small data between mcu2_0 and mpu1_0, but I would like to use a DDR region as a Shared Memory between these cores to be able to exchange large amounts of data and pass the pointer to the data region or something to exchange say 100MB data.

    Yes ,Currently VRING buffers has data limit to transfer of 256*512 bytes maximum between cores but since you want to use more space in  DDR region then you need to reserve certain area in DDR regions and point its address and pass  the pointer in VRING buffers to the other core.

    I believe I could use the reserved memory regions of the particular core from the dts as the shared memory, right?
    If yes, how does this work with the VRING Buffers, as I assume these are also part of this reserved memory region.

    Yes .you can use any available memory in DDR but be cautious that memory should not overlap with any existing reserved regions both on Linux side and baremetal side. VRING buffers remains same , instead of data now address pointers will be carried between cores. You can find already reserved memories in dts file of linux and r5 mpu file in baremetal.

    Regards

    Tarun Mukesh

  • Hi Tarun,

    I could reserve the memory region or update the existing regions in the dts and update the linker file of the corresponding mcu to match the memory structure.

    For instance, I have some 20+MB that I could now use for data exchange between mpu1_0 and mcu2_0.

    The question is, how exactly would I be able to write it from mpu1_0 running Linux?

    I believe reading this memory from mcu2_0 or writing from mcu2_0 should probably be like, taking the address location and directly using it.
    Whereas in Linux, I believe the reserved memory is somehow part of the kernel driver (probably exposed through devfs or something) dd or something similar wouldn't work or?, how should I write/read this memory region from Linux Userspace?

    Thank you.

    Best,
    Moses

  • Hello Moses,

    Each VRING buffer space is also reserved memory region in DDR and A72 will be writing data into the reserved VRING Memory region and other cores are accessing it right. So similar way you have new reserved certain section of memory and it has to be accessed the same way.

    
    

    k3_r5_rproc_da_to_va API in driver will convert the direct address to virtual address in linux

     May i please know your inputs on this ?

    Regards

    Tarun Mukesh

  • Hi Tarun,

    Answering my own question,

    I could access this memory region using /dev/mem (I assumed it would be through rpmsg_ctrl or something before).
    So I could mmap the memory regions and write or read from Linux.

    Thanks.

    Best,
    Moses