• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 520 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.

TDA4VM: How to use spin lock between A72 and R5f

Frank DU
Prodigy 190 points

Part Number: TDA4VM

Tool/software:

Hi, 

We by now use readFlag/writeFlag to protect the data safe when transmit data from a72(qnx) to mcu(r5f) via shared memory in user space.
But We think the shared variables of readFlag and writeFlag is not safe in the access of two cores
So we prefer spinlock, to understand the special user case, please see the details below, spinlock is supposed to protect critical process of readFlag and writeFlag.

Question:

① InterruptDisable is the standard interface of qnx, Does it work well that can disable any interrupt and no any scheduling.
② Is there any cache inconsistency issue between a72 and r5f for readFlag/writeFlag
(The shared memory is DDR section which configed by TI for cores logs, address: 0xB2028000u ). If it does, how to avoid?
③ There are 256 spin locks configured in TI sdk, Have any spin locks already used by TI SDK itself? Is it ok if we try to use them from register[0]? (One spin lock is enough for us at present)
Thanks a lot.

[details]

SDK version: 8.2

reference: ./PSDKRA/pdk_jacinto_08_02_00_21/packages/ti/csl/src/ip/spinlock/V1/csl_spinlock.h

  • 0
    TI__Guru*** 134091 points

    Hi,

    Yes - InterruptDisable() (qnx.com) will disable all interrupts, recommend reviewing QNX documentation for details on usage.

    As the readflag/writeFlag is a memory mapped register, all accesses should be non-cached, based on the memory mapping.

     TI SDK does make use of spinlocks one example is below and shows reference usage on QNX.   There is no consolidated list to my knowledge.

    • ti-processor-sdk-rtos-j784s4-evm-09_02_00_05/app_utils/utils/ipc/src/app_ipc_qnx.c

    The spinlocks which would be used by OpenVx are listed in below files:

    • tiovx/source/platform/psdk_j7/common/soc/tivx_platform_psdk_j7xx.h

    Regards,

    kb

  • 0 in reply to KB
    Prodigy 190 points

    Thank you for reply the questions in time.

    About question ② ， Let me explain the idea in detail.

    >As the readflag/writeFlag is a memory mapped register, all accesses should be non-cached, based on the memory mapping.


    -> readflag/writeFlag here will not map to the spinlock register. They are normal variables just defined in shared memory.
    Because it will take much time to copy local data to shared memory , so the spinlock is only used to protect flag(readFlag or writeFlag) and flag is used to protect the data,  both flag and data are in shared memory, that is to ensure the critical section take no much time cost.  And the shared memory is a section of remote core logging(APP_LOG_MEM) defined by TI, we try to re-use it since the section is still none operation at present. Please reference the picture from TI memory map view below.

    For other section, such as TIOVX_OBJ_DESC_MEM, is saying"must be non-cached", but APP_LOG_MEM not.
    So is the user able to configure APP_LOG_MEM as a non-cached section? (the flag is just defined at the beginning of APP_LOG_MEM section)
    And only 2 bytes for flag is configured as non-cached, is it possible?

    Best Regards,

  • +1 in reply to Frank DU
    TI__Guru*** 134091 points

    Hi,

    If the R5 needs to share data via DDR with the A72, the R5 S/W needs to do R5-side cache maintenance as a producer of the data, but the A72 will not need to do anything special as a consumer.

    For the reverse direction, the A72 to R5, cache maintenance is not required, as these accesses participate in the coherency protocol and MSMC maintains a snoop cache which will be consulted when the R5 access passes through MSMC.  For coherency 'inner sharable' is the required setting for ARMv8 (A72 in this case) based systems.

    Regards,

    kb

  • 0 in reply to KB
    Prodigy 190 points

    Hi,

    I have learned it. Thank you.