• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 124 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.

AM6422: rpmsg send

wanglili 王
Intellectual 680 points
Part Number: AM6422

Tool/software:

Hello， Regarding the inter-core communication using SDK 8.6 between Linux and RTOS, where only 512 bytes are transmitted per frame (with 496 bytes being actually effective), is it feasible to simply modify the message-based approach to increase the data length transmitted per frame from 512 bytes to 1024 bytes or more? If it is possible, what modifications would be required in both the real-time core (RTOS) and non-real-time core (Linux) parts? If it is not possible, could you please explain the specific reasons? Currently, we prefer not to implement this using shared RAM. Thank you very much!

  • 0
    TI__Mastermind 20256 points

    Hello,

    The concerned expert is out of office today. Please expect a delay in response. Feel free to ping this thread if you don't a response by Wednesday next week.

    Regards,

    Nihar Potturu. 

  • 0
    TI__Guru** 100960 points

    Hello Wanglili,

    No, TI does not support increasing the size of the RPMsg data frame for messages between Linux and MCU+ SDK.

    RPMsg between two MCU+ instances does support configuring the buffer size. However, the Linux RPMsg framework requires a fixed buffer of 512 bytes with a 16 byte header.

    For more information, refer to the MCU+ SDK's driver documentation for RPMsg:
    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/10_01_00_32/exports/docs/api_guide_am64x/DRIVERS_IPC_RPMESSAGE_PAGE.html 

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 680 points

    Hello，

        When you say it's not supported to modify (the length), do you mean that even by modifying the kernel, we still can't increase the length beyond 512? What determines this? I found the following code snippet in the Linux source code. From my understanding, these two definitions can be modified, but in practice, the changes didn't take effect after I modified them. Could you explain this part?

        

  • 0 in reply to wanglili 王
    TI__Guru** 100960 points

    Hello Wanglili,

    Changing the size of RPMsg buffers

    We can answer questions about TI software on these forums, but we cannot support questions about modifying TI software to do something custom.

    The Linux RPMsg framework does not support any buffer sizes other than 512 bytes. It is possible that this value is hardcoded into many different files across remoteproc, rpmsg, virtio drivers.

    Changing the number of RPMsg buffers

    I would expect that we SHOULD be able to modify the number of VIRTIO buffers from 256 buffers in each direction (512 total, 256 RX and 256 TX). However, the last time I tried digging into it I was unable to get it working. If you are able to get a reduced number of VIRTIO buffers working, I would love to see what you did so that I can document it.

    The number of VIRTIO buffers should be listed in the resource table of the MCU+ project. That define you pointed to lists the Max number of buffers. Without re-checking the driver, I think it is treated like an upper limit, rather than as the actual number of buffers.

    Something that occurs to me, PRU RPMsg uses 16 buffers in each direction by default instead of 256. Maybe we can use that as a template to figure out what changes would be required to do something similar for R5 cores.

    PRU resource table is here:
    https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am64x/PRU_RPMsg_Echo_Interrupt0/resource_table.h

    and in Linux SDK 8.6, PRU rpmsg uses a different driver than the MCU+ cores. It isn't until SDK 11.1 where we will combine the PRU RPMsg driver and the MCU+ cores' RPMsg driver.

    Regards,

    Nick