boards: nordic: ipc: added dcache alignement

The nRF54 and nRF92 chips has data cache, which means
the ICMsg and ICBMsg must be configured to follow required
cache alignment of the shared memory.
The `dcache-alignement` needs to be defined for that.

Signed-off-by: Dominik Kilian <Dominik.Kilian@nordicsemi.no>
This commit is contained in:
Dominik Kilian 2024-10-23 14:23:00 +02:00 committed by David Leach
commit cbaafe209c
10 changed files with 29 additions and 3 deletions

View file

@ -24,6 +24,7 @@
cpuapp_cpurad_ipc: ipc-2-3 {
compatible = "zephyr,ipc-icbmsg";
dcache-alignment = <32>;
status = "disabled";
mboxes = <&cpuapp_bellboard 18>,
<&cpurad_bellboard 12>;

View file

@ -24,6 +24,7 @@
cpuapp_cpurad_ipc: ipc-2-3 {
compatible = "zephyr,ipc-icbmsg";
dcache-alignment = <32>;
status = "disabled";
mboxes = <&cpuapp_bellboard 18>,
<&cpurad_bellboard 12>;

View file

@ -40,12 +40,21 @@ Configuration
The backend is configured using Kconfig and devicetree.
When configuring the backend, do the following:
* If at least one of the cores uses data cache on shared memory, set the ``dcache-alignment`` value.
This must be the largest value of the invalidation or the write-back size for both sides of the communication.
You can skip it if none of the communication sides is using data cache on shared memory.
* Define two memory regions and assign them to ``tx-region`` and ``rx-region`` of an instance.
Ensure that the memory regions used for data exchange are unique (not overlapping any other region) and accessible by both domains (or CPUs).
* Define the number of allocable blocks for each region with ``tx-blocks`` and ``rx-blocks``.
* Define MBOX devices for sending a signal that informs the other domain (or CPU) of the written data.
Ensure that the other domain (or CPU) can receive the signal.
.. caution::
Make sure that you set correct value of the ``dcache-alignment``.
At first, wrong value may not show any signs, which may give a false impression that everything works.
Unstable behavior will appear sooner or later.
See the following configuration example for one of the instances:
.. code-block:: devicetree
@ -63,6 +72,7 @@ See the following configuration example for one of the instances:
ipc {
ipc0: ipc0 {
compatible = "zephyr,ipc-icbmsg";
dcache-alignment = <32>;
tx-region = <&tx>;
rx-region = <&rx>;
tx-blocks = <16>;

View file

@ -24,6 +24,9 @@ Configuration
The backend is configured via Kconfig and devicetree.
When configuring the backend, do the following:
* If at least one of the cores uses data cache on shared memory, set the ``dcache-alignment`` value.
This must be the largest value of the invalidation or the write-back size for both sides of the communication.
You can skip it if none of the communication sides is using data cache on shared memory.
* Define two memory regions and assign them to ``tx-region`` and ``rx-region``
of an instance. Ensure that the memory regions used for data exchange are
unique (not overlapping any other region) and accessible by both domains
@ -32,6 +35,12 @@ When configuring the backend, do the following:
domain (or CPU) that data has been written. Ensure that the other domain
(or CPU) is able to receive the signal.
.. caution::
Make sure that you set correct value of the ``dcache-alignment``.
At first, wrong value may not show any signs, which may give a false impression that everything works.
Unstable behavior will appear sooner or later.
See the following configuration example for one of the instances:
.. code-block:: devicetree
@ -49,6 +58,7 @@ See the following configuration example for one of the instances:
ipc {
ipc0: ipc0 {
compatible = "zephyr,ipc-icmsg";
dcache-alignment = <32>;
tx-region = <&tx>;
rx-region = <&rx>;
mboxes = <&mbox 0>, <&mbox 1>;

View file

@ -32,7 +32,7 @@ properties:
For example:
Side A: no data cache
Side B: 32 Bytes write-back size, 16 Bytes invalidation size
dcache-alignment = 32; for both
dcache-alignment = <32>; for both
mboxes:
description: phandle to the MBOX controller (TX and RX are required)

View file

@ -23,6 +23,7 @@
ipc {
ipc0: ipc0 {
compatible = "zephyr,ipc-icmsg";
dcache-alignment = <32>;
tx-region = <&sram_tx>;
rx-region = <&sram_rx>;
mboxes = <&cpuapp_vevif_rx 20>, <&cpuapp_vevif_tx 21>;

View file

@ -23,6 +23,7 @@
ipc {
ipc0: ipc0 {
compatible = "zephyr,ipc-icbmsg";
dcache-alignment = <32>;
tx-region = <&sram_tx>;
rx-region = <&sram_rx>;
tx-blocks = <16>;

View file

@ -23,6 +23,7 @@
ipc {
ipc0: ipc0 {
compatible = "zephyr,ipc-icmsg";
dcache-alignment = <32>;
tx-region = <&sram_tx>;
rx-region = <&sram_rx>;
mboxes = <&cpuflpr_vevif_rx 21>, <&cpuflpr_vevif_tx 20>;

View file

@ -23,6 +23,7 @@
ipc {
ipc0: ipc0 {
compatible = "zephyr,ipc-icbmsg";
dcache-alignment = <32>;
tx-region = <&sram_tx>;
rx-region = <&sram_rx>;
tx-blocks = <18>;

View file

@ -1434,11 +1434,11 @@ const static struct ipc_service_backend backend_ops = {
}; \
BUILD_ASSERT(IS_POWER_OF_TWO(GET_CACHE_ALIGNMENT(i)), \
"This module supports only power of two cache alignment"); \
BUILD_ASSERT((GET_BLOCK_SIZE_INST(i, tx, rx) > GET_CACHE_ALIGNMENT(i)) && \
BUILD_ASSERT((GET_BLOCK_SIZE_INST(i, tx, rx) >= GET_CACHE_ALIGNMENT(i)) && \
(GET_BLOCK_SIZE_INST(i, tx, rx) < \
GET_MEM_SIZE_INST(i, tx)), \
"TX region is too small for provided number of blocks"); \
BUILD_ASSERT((GET_BLOCK_SIZE_INST(i, rx, tx) > GET_CACHE_ALIGNMENT(i)) && \
BUILD_ASSERT((GET_BLOCK_SIZE_INST(i, rx, tx) >= GET_CACHE_ALIGNMENT(i)) && \
(GET_BLOCK_SIZE_INST(i, rx, tx) < \
GET_MEM_SIZE_INST(i, rx)), \
"RX region is too small for provided number of blocks"); \