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.

AM6548: Need synchronization mechanism for R5 and A53

Part Number: AM6548

Hi TI,

I need to send data from R5 to A53 for my application at the rate of 6 milli second. data is in the form of 10 float values. rpmsg takes approx. 6-7 milli sec to send the data rom R5 to A53 as seen from the virtio driver logs. I need to send it more faster compared to what rpmsg now works on. the method of sending should be synchronous. Is there a optimum way to send data in synchronized way from R5 to A53 at rate faster than 6milli sec ?

Is there any more optimized library or API to do this ? or is there any other method to do it ?

Let me know.

Thanks,

Sarfaraz

  • Hi TI,

    Any update on the above issue ?

  • This issue is more of delay in DDR update. When we update value from R5 to A53 in DDR , it is getting late updated in DDR than the rate at which R5 is writing in DDR.

  • Hi Sarfaraz,

    Are you sending the data as part of the rpmsg packet itself, or using separate shared memory?

    rpmsg is the only interface available to userspace level.

    regards

    Suman

  • Hi Suman,

    Thanks for your reply. we tried both the ways 

    1. Sending data as part of rpmsg as our data is small (10 float values). As rpmsg takes 6milli sec to transfer from r5 to a53 this scenario is not valid for us to use.

    2. Other scenario that we tried is r5 copies data to DDR and A53 reads from DDR. but we observed that there is some issue in reading the data from DDR. Data is not getting immediately updated in DDR as R5 writes it is taking some time for data to appear in DDR. looks like some coherency issue. we made writeback from R5 side still the delay in update for data in DDR. Any solution to this problem ?

    Thanks,

    Sarfaraz

  • 2. Other scenario that we tried is r5 copies data to DDR and A53 reads from DDR. but we observed that there is some issue in reading the data from DDR. Data is not getting immediately updated in DDR as R5 writes it is taking some time for data to appear in DDR. looks like some coherency issue. we made writeback from R5 side still the delay in update for data in DDR. Any solution to this problem ?

    Sarfaraz, unfortunately on AM65x the R5 is not cache coherent with the A53 caches, see https://e2e.ti.com/support/processors-group/processors/f/processors-forum/987041/am6548-cache-coherency-between-a53-and-r5f-for-ddr-msmc-sram for more details. So writes from R5 will not automatically invalidate the caches on the A53. The memory will need to be either mapped non-cached or you need to invalidate the A53 caches explicitly.

      Pekka

  • Thanks for the reply. In our scenario we are running Linux on A53 and TI-RTOS on R5. is there a way to map the shared memory as non - cached from Linux . I could not find a option for such setting in device tree where we do memory carveout.

    Thanks,

    Sarfaraz

  • Sarfaraz,

    Unfortunately I don't think there is a mmap() parameter to map normal DDR memory as uncached from user space. We have the A53 and R5 shared memory example planned to in an AM64x SDK later this year. That example should be usable on AM65x as well. Until The thread https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1080077/am6548-update-in-ddr-from-r5f-is-not-reflected-in-a53/ is perhaps trying to address the same underlying issue.

    My suggestion for the use case you have is to use rpmsg, which looks to be hundreds of microseconds level latency (not the 6-7ms you seem to have observed in maybe an older SDK. Printouts in the linked thread and below for a send from A53, send back from R5 sequence based on the latest AM65x SDK (8.1).

    root@am65xx-evm:~# 
    root@am65xx-evm:~# modprobe rpmsg_client_sample count=10
    root@am65xx-evm:~# [582671.428404] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x400 -> 0xd!
    [582671.428685] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 1 (src: 0xd)
    [582671.428873] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 2 (src: 0xd)
    [582671.429539] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 3 (src: 0xd)
    [582671.429702] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 4 (src: 0xd)
    [582671.429861] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 5 (src: 0xd)
    [582671.430020] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 6 (src: 0xd)
    [582671.430168] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 7 (src: 0xd)
    [582671.430315] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 8 (src: 0xd)
    [582671.430469] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 9 (src: 0xd)
    [582671.430615] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: incoming msg 10 (src: 0xd)
    [582671.430627] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: goodbye!
    
    root@am65xx-evm:~# uname -a
    Linux am65xx-evm 5.10.65-rt53-g541ec9a699 #1 SMP PREEMPT_RT Tue Dec 21 02:58:35 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
    root@am65xx-evm:~# 

      Pekka