On STM32MP1 devices, are 32-bit accesses to SRAM1,2,3,4 atomic?

[TNaum]

We would like to share data between the A7-core and the M4-core on an STM32MP1 device. Those cores both have access to the SRAM1,2,3,4 . The M4-core is connected directly via the AHB interconnect, the A7-core is connected via the AXI-based NIC-400 interconnect which has access to the AHB.

Since both interconnects have a bit-width of 32 bits or more, I am wondering if writing or reading to/from a 32 bit address will always be atomic, at least for aligned accesses. So for example, if the A7 is constantly writing a uint32 into a commonly known memory address in SRAM1 and the M4 is constantly reading this address, is it guaranteed that the M4 will never read a partially updated value?

Thanks in advance

[PatrickF]

I confirm there is no mechanism which could split a single and aligned 32-bit write/read from A7 or M4 to SYSRAM.

Note that in case SYSRAM is part of cached area of Cortex-A7, you will have to play with cache setting or cache maintenance low level command to ensure your data is really in SYSRAM (which might not be easy with Linux).

Better and easier would be to use existing mechanism using IPCC interrupts and RPMsg/OpenAMP.

See https://wiki.st.com/stm32mpu/wiki/Linux_RPMsg_framework_overview and also https://wiki.st.com/stm32mpu/wiki/Exchanging_buffers_with_the_coprocessor

Regards.

[TNaum]

Okay, I understand how this affects SYSRAM but I was referring to writes/read to/from SRAM1,2,3,4 which are M4-dedicated. I would be surprised if those are part of any cached area for the A7?

Can you confirm that

a) it still holds true that writes/reads are atomic to that memory region

b) it is not cached in any way?

The IPCC mechanism is not satisfactory for us because as far as I have seen it, you always have to wait until the opposite side has confirmed your signal before writing something new. And anyways, if we use one of the hardware synchronization mechanisms (HSEM or IPCC), we still have to ensure that data accesses are not cached. So, good that you brought that topic up but I still hope that accesses to SRAM1,2,3,4 are not cached in any way.

Regards.

[PatrickF · Accepted solution]

Hi, I read too fast !

a) Same behavior for SRAM (this is true for any 32-bit aligned access in general)

b) According to https://wiki.st.com/stm32mpu/wiki/Exchanging_buffers_with_the_coprocessor#RPMsg_protocol_awareness, buffer are in non-cacheable area. If you don't use RPMsg, I think it will depend on how you define your buffers within Linux.

I'm not Linux specialist, but I think that all memory area are defined as cached within Linux, but non-cached if it is some kind of HW related buffer (like message/descriptors buffers for any master peripherals).

Regards.

[TNaum]

Okay, thanks for clarifying this. This answers my question if those accesses can be assumed to be atomic.