• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 256 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.

AM6442: Spin lock from A53 linux

Chris
Intellectual 301 points
Part Number: AM6442

Dear TI team,

In our application, we require fast synchronization between A53 cores, R5F cores, and M4F. While I have come across examples of spinlock usage for R5F cores, I haven't found any instances of its usage in the processor SDK or A53. I would appreciate some insights into the following questions:

  1. Is it possible to use spin lock on A53 cores (using Linux)? If so, are there any available examples or application notes demonstrating its usage?

  2. It has been observed that spin lock is available in the Main domain. Can M4F utilize the spin lock mechanism by using RAT? If not, do we have any alternatives for achieving similar functionality?

Thank you

Chris

  • 0
    TI__Guru** 100540 points

    Hello Chris,

    I will be commenting from the Linux side. We may pass your thread around to different team members as needed to get all parts of it answered.

    Spinlocks with Linux

    To confirm, are you talking about Linux userspace code, Linux kernel driver code, or something else on the A53?

    There is definitely a Linux spinlock driver, see arch/arm64/boot/dts/ti/k3-am64-main.dtsi and Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml . However, I am not aware of any example code for using the driver. I dug around some old development repos and so far this is the most I have found: https://git.ti.com/cgit/rpmsg/hwspinlock/commit/?id=31cf5ea7fa7dc39e554683daf9248bc1f5456bac 

    Main domain spinlocks from the M4F

    My understanding of what is "technically" supported on AM64x MCU+ SDK: M4F drivers support working with MCU domain peripherals, R5F drivers support using MAIN domain peripherals (as per the NOTE at the top of https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_06_00_45/exports/docs/api_guide_am64x/RELEASE_NOTES_08_06_00_PAGE.html ).

    However, when I look at the spinlock driver code, I don't see any reason why the M4F could not use the driver with a spinlock in the main domain (keep in mind I am NOT an MCU+ programmer). If the spinlock base address is somewhere where there is already something else in the M4F's local memory, you should be able to use the RAT to transform that base address to a different local address, and then pass in the local address to the driver as described here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1192281/faq-am62x-am64x-updating-the-region-based-address-translation-rat-settings

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 301 points

    Thanks Nick,

    Nick Saulnier said:
    To confirm, are you talking about Linux userspace code, Linux kernel driver code, or something else on the A53?

    Basically we need to share some data among R5F, M4F and A53(Linux) and planning to use Spinlock as a synchronization aiding object. So, as per my understanding we need to share the data from the Linux user space

    Nick Saulnier said:
    My understanding of what is "technically" supported on AM64x MCU+ SDK: M4F drivers support working with MCU domain peripherals, R5F drivers support using MAIN domain peripherals

    Yes, I did have some concerns about the feasibility of this. If it's possible to use a spin lock with RAT, as mentioned in your RAT FAQ, it would definitely make things easier.

    Thank you

    Chris

  • 0 in reply to Chris
    TI__Guru** 100540 points

    Hello Chris,

    Got it. If you need an example of setting up shared memory from the Linux side, take a look at the rpmsg_char_zerocopy example: https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

    My suspicion is just that the developers don't test M4F controlling the main domain spinlock (not that it is not possible to use).

    Keep in mind that the RAT is basically nothing but some combinational logic (i.e., it isn't even flops that are latched in on a clock signal). I would expect the M4F to be able to access that memory space just fine, even if it needs to translate that system address to a different local address.

    Regards,

    Nick