Cover image for IPCC

IPCC

Created:Updated:
Linux
, 
Words 3.1k
Views
Visitors
Timeline

Timeline

2026-07-02

init

This article introduces inter-process communication (IPC) and its hardware controller IPCC, focusing on STM32MP157 as an example. It explains the working modes (simplex, half-duplex, full-duplex) of the 6 bidirectional channels (12 sub-channels) of IPCC and their specific uses in ST's official configuration, including channels 1 and 2 used for the RPMsg framework to implement message transmission between A7 and M4, and channel 3 used for the RemoteProc framework to control the coprocessor lifecycle. The article also explains that IPCC only provides an interrupt notification mechanism, with actual data transmitted through shared memory, and introduces the related 8 registers and the interrupt control of each of the two processors. In addition, it mentions the integration of the OpenAMP framework on the Linux side and the M4 side.

IPC（Inter-Process Communication, inter-process communication) refers to the interaction between data of two processes (in a broad sense, inter-process, including processes of heterogeneous cores), which is implemented through the inter-processor communication controller IPCC（Inter-Process Communication controller, IPC controller) is implemented. IPCC is part of the hardware, used for signal exchange between two CPUs. The mailbox depends on IPCC. The IPCC hardware module of STM32MP157 has 6 bidirectional channels, each channel is divided into two sub-channels, so 6 bidirectional channels have a total of 12 sub-channels. The figure shows the structural block diagram of communication between the A7 core and M4 core through IPCC.

IPC communication structure block diagram
IPC communication structure block diagram

When a data packet is placed into shared memory, the CPU needs to interrupt or ‘notify’ the other CPU that there is a new data packet in the shared memory to be processed. The other CPU processes it after receiving the signal. This is done using the IPCC hardware interrupt mechanism.。

The interrupt controller of the A7 core is GIC, and the interrupt controller of the M4 core is NVIC. The role of IPCC is like a sentinel, controlling when data can be received and when data can be sent; the entire process is controlled by IPCC.

IPCC only provides a mechanism for information exchange between processors; it does not have data transmission capability., that is,The data to be exchanged between processorsis not transmitted in IPCC,but is transmitted in shared memory.。

IPCC channels

The working modes of the 6 channels of IPCC can be divided into simplex, half-duplex, and full-duplex:

  • There are 6 channels in the direction from CPU1 to CPU2 (P1_TO_P2 sub-channels, P1 represents CPU1, P2 represents CPU2)
  • There are 6 channels in the direction from CPU2 to CPU1 (P2_TO_P1 sub-channels, P1 represents CPU1, P2 represents CPU2)

As shown in the table below, in the IPCC communication model configured by ST, these 6 channels are used as different software frameworks, among which:

  • Channel 3 is in simplex mode and is used as the RemoteProc framework. The main processor can load the coprocessor firmware and control the coprocessor lifecycle through this framework;
  • Channel 2 is in full-duplex mode and is used as the RPMsg framework to transmit messages from A7 to M4;
  • Channel 1 is in full-duplex mode and is used as the RPMsg framework to transmit messages from M4 to A7.
ChannelModeUsageSoftware client framework: Cortex-A7 (non-secure)Software client framework: Cortex-M4
Channel 1Full duplexRPMsg transmission from Cortex-M4 to Cortex-A7:
1. Cortex-M4 uses this channel to indicate that a message is available
2. Cortex-A7 uses this channel to indicate that the message has been processed		RPMsg frameworkOpenAMP
Channel 2Full duplexRPMsg transmission from Cortex-A7 to Cortex-M4:
1. Cortex-A7 uses this channel to indicate that a message is available
2. Cortex-M4 uses this channel to indicate that the message has been processed		RPMsg frameworkOpenAMP
Channel 3SimplexCortex-M4 shutdown requestRemoteProc frameworkCprocSync cube utility
Channels 4/5/6Unused

Simplex communication: It means the signal is transmitted in only one direction, and can only send or receive.

Half-duplex communication: Signals can be transmitted in both directions, but at any one time only sending or receiving is allowed (1-Wire and I2C are both half-duplex communication)

Full-duplex communication: Full-duplex communication means data is transmitted in both directions simultaneously

It can be seen that in the framework configured by ST:

  1. The RemoteProc software framework solves the problem of remote processor lifecycle
  2. The RPMsg software framework solves the problem of inter-core communication

These two are the concerns in multi-core processor communication!

In the Linux kernel, ST has already ported the RemoteProc and RPMsg software frameworks. In the OpenAMP library used by the M4, there are also corresponding RemoteProc and RPMsg software frameworks. The M4 mainly relies on the existing software frameworks in the OpenAMP library to communicate with the A7.

Note: In order to allow the main core to control the coprocessor, the OpenAMP framework is designed on the Linux side. At the same time, to be compatible with the Linux-side OpenAMP framework, the M4-related vendors have also designed an OpenAMP framework. The two can be interconnected, but there are certain differences; they just share the same name.

The A7 and M4 of the STM32MP157 actually transfer data through Channel 1 and Channel 2:

Data transfer between Cortex-A7 and Cortex-M4
Data transfer between Cortex-A7 and Cortex-M4

IPCC registers

There are 8 registers related to IPCC. The register area is divided into two regions, each occupied by one processor to prevent read/write access conflicts. As shown in the table below, the first 4 registers are occupied by Processor 1, and the last 4 registers are occupied by Processor 2.

IPCC provides dedicated interrupts for the processors. Each processor has its own status mask register bits and set or clear register bits for each channel.

registerDescriptionBit (n denotes 1~6)
IPCC_C1CREnable/Disable Processor 1 TX channel free interrupt / RX channel occupied interruptTXFIE、RXOIE
IPCC_C1MRMask/Unmask Processor 1 TX channel X free interrupt / RX channel X occupied interruptCHnFM、CHnOM
IPCC_C1SCRProcessor 1 TX/RX channel X status bit set/clearCHnS、CHnC
IPCC_C1TOC2SRChannel occupied/freeCHnF
IPCC_C2CREnable/Disable Processor 2 TX channel free interrupt / RX channel occupied interruptTXFIE、RXOIE
IPCC_C2MRMask/Unmask Processor 2 TX channel X free interrupt / RX channel X occupied interruptCHnFM、CHnOM
IPCC_C2SCRProcessor 2 TX/RX channel X status bit set/clearCHnS、CHnC
IPCC_C2TOC1SRChannel occupied/freeCHnF

IPCC_C1CR

IPCC Processor 1 control register

31302928272625242322212019181716
ResResResResResResResResResResResResResResResTXFIE
rw
1514131211109876543210
ResResResResResResResResResResResResResResResRXOIE
rw
  • Bits 17~31 and bits 1~15 are reserved bits and must be kept at their reset value.
  • Bit 16, TXFIE: Processor 1 transmit (TX) channel free interrupt enable bit, associated with IPCC_C1TOC2SR associated, when this bit is:
    • 1: Enable Processor 1 transmit (TX) channel free interrupt;
    • 0: Disable Processor 1 transmit (TX) channel free interrupt.
  • Bit 0, RXOIE: Processor 1 receive (RX) channel occupied interrupt enable bit, associated with IPCC_C2TOC1SR associated, when this bit is:
    • 1: Enable Processor 1 receive (RX) channel occupied interrupt;
    • 0: Disable Processor 1 receive (RX) channel occupied interrupt.

IPCC_C1MR

IPCC processor 1 mask register

31302928272625242322212019181716
ResResResResResResResResResResCH6FMCH5FMCH4FMCH3FMCH2FMCH1FM
rwrwrwrwrwrw
1514131211109876543210
ResResResResResResResResResResCH6OMCH5OMCH4OMCH3OMCH2OMCH1OM
rwrwrwrwrwrw

  • Bits 22~31 and bits 6~15 are reserved bits and must be kept at their reset value.

  • Bits 1621,**CH1FM**CH6FM, processor 1 transmit (TX) channel X idle interrupt mask bit, is IPCC_C1TOC2SR.CHxF associated, when this bit is:

    • 1: The transmit (TX) channel X idle interrupt is masked;
    • 0: The transmit (TX) channel X idle interrupt is not masked.

  • Bits 05,**CH1OM**CH6OM, processor 1 receive (RX) channel X occupancy interrupt mask bit, is IPCC_C2TOC1SR.CHxF associated, when this bit is:

    • 1: The receive (RX) channel X occupancy interrupt is masked;
    • 0: The receive (RX) channel X occupancy interrupt is not masked.

IPCC_C1SCR

IPCC processor 1 status set/clear register

31302928272625242322212019181716
ResResResResResResResResResResCH6FMCH5FMCH4FMCH3FMCH2FMCH1FM
rwrwrwrwrwrw
1514131211109876543210
ResResResResResResResResResResCH6OMCH5OMCH4OMCH3OMCH2OMCH1OM
rwrwrwrwrwrw
  • Bits 22~31 and bits 6~15 are reserved bits and must be kept at their reset value.
  • Bits 16~21, CH1S~CH6S, processor 1 transmit (TX) channel X status set bit, is IPCC_C1TOC2SR.CHxF associated, when this bit is set:
    • 1: The processor 1 transmit (TX) channel X status bit is set, that is, CHnF is set to 1, indicating that the channel is occupied;
    • 0: No action.
  • Bits 0~5, CH1C~CH6C, processor 1 receive (RX) channel X status clear bit, is IPCC_C2TOC1SR.CHxF associated, when this bit is set:
    • 1: The processor 1 receive (RX) channel X status bit is cleared;
    • 0: No action

IPCC functional description

IPCC’s control of processor communication is actually implemented through interrupts, called inter-processor interrupts (IPI). Each processor has two interrupt lines, which are:

  • One is used for RX channel occupancy (the transmitting processor posts data);
  • One for TX channel idle (the receiving processor reads communication data).

Each channel has interrupt masking:

  • Channel occupied mask (bit CHnOM);
  • Channel free mask (bit CHnFM).

In the context of computers, microcontrollers, or hardware peripherals (such as communication controllers like DMA, Mailbox, IPCC, etc.),“Mask” means to “turn off” or “filter out” an interrupt signal so that it is not reported to the CPU.。

Each subchannel has two operating modes:

  • Simplex mode (each channel has its own communication data storage location);
  • Half-duplex mode (a single channel associated with a bidirectional communication data storage location).

The communication data resides in shared memory (note that the shared memory is not part of the IPCC). For each communication, the IPCC module provides achannel status flag CHnF(n can take values from 1 to 6, indicating the corresponding channel):

  • When CHnF=0, it indicates that the associated channel is idle.(It can also be considered that the communication data has already been read by the receiving processor, and the channel is in an idle state at this time),At this time, the sending processor can occupy this channel to send data;
  • When CHnF=1, it indicates that the associated channel has been occupied.(That is, the communication data has already been published by the sending processor),At this time, the receiving processor can access the channel to read data.

IPCC provides a non-blocking signaling mechanism for channel management:

  • Message availability interrupt;
  • Channel flow control (for example, generating a TX channel idle interrupt is called flow on, and when the channel is occupied, it is called flow off).

Applications benefit from non-blocking interrupt-based message exchange and channel flow control for inter-core communication. Each subchannel has a transmission direction:

  • Transmitted from CPU1 and received by CPU2;
  • Or transmitted from CPU2 and received by CPU1.

Simplex transmission mode

The figure below shows the IPCC simplex transmission mode diagram.

  • When the channel status flag indicates the channel is occupied (CHnF=1), this is because the receiver has not released the channel from the previous message. At this time, the channel idle interrupt is unmasked, and then wait for the TX idle interrupt.
  • Once the receiver releases the channel, a channel idle interrupt is generated (stream open). When the channel idle interrupt is generated, the channel idle interrupt is masked, and the message can be written to the data buffer. Subsequently, the channel status flag is set to occupied, which triggers the channel occupied interrupt at the receiving end.

Simplex Transmission
Simplex Transmission

Simplex Reception Mode

The figure below shows the IPCC simplex reception mode diagram. When a channel occupied interrupt is generated, the receiving end determines which channel is occupied, masks the corresponding channel occupied interrupt, and then can read data from the shared memory. Once the data is read, the channel status flag CHnF is cleared (CHnF=0), and the channel occupied interrupt is unmasked.

Simplex Reception
Simplex Reception

Half-duplex Transmission Mode

The figure below shows the IPCC half-duplex transmission mode diagram.

The half-duplex process allows a single shared buffer to be used to transfer a message from the sender to the receiver, and then send a response (Response pending) from the receiver back to the sender.

Data transmission process at the sending end:

  • Software variableresponse_pending = 1Indicates that the sender is waiting for the receiver’s response.
  • response_pending = 0Indicates that the receiver’s response has been obtained.

First, the sender checks the channel status flag. If the channel status flag indicates that the channel is occupied (CHnF=1), that is, because the receiver has not yet sent a response to the previous message, the sender waits for the response. If the channel is idle, the sender can write the message into the shared memory.

Subsequently, the channel status flag is set to occupied, which triggers the RX channel occupied interrupt at the receiving end. Once the channel status flag CHnF=1, the channel idle interrupt is unmasked. The channel idle interrupt indicates whether the response sent by the receiver is available. When the channel idle interrupt is generated (response ready), the sender determines which channel to release and masks the corresponding channel idle interrupt, and then can read the response from the shared memory.

Response process at the receiving end:

The receiving processor waits for the software variableresponse_pendingwhether it is equal to 1. If it is equal to 1, the receiving end writes the response into the shared memory (publishes the response). Once the response is published, the channel status flag CHnF is cleared by CHnC, so CHnF becomes 0, and the receiving end unmasks the channel occupied interrupt (CHnOM = 0).

Half-duplex Transmission Mode
Half-duplex Transmission Mode

Half-duplex Reception Mode

The figure below shows the IPCC half-duplex reception mode diagram.

  • Receiving end reads data: When a channel occupied interrupt is generated, the receiving end determines which channel is occupied, masks the corresponding channel occupied interrupt, and then receives data from the shared memory. The channel is released only after the receiver sends the response to the shared memory.
  • Sender reads response: To receive the response, the channel idle interrupt is unmasked. The sending processor checks which channel becomes idle, masks the related channel idle interrupt, and then reads the response from the shared memory.

IPCC Half-duplex Reception
IPCC Half-duplex Reception

IPCC provides a non-blocking signaling mechanism for 6 bidirectional channels to atomically publish and retrieve communication data. The non-blocking approach allows the processor to not block and wait when the channel conditions are not met, but instead to handle other tasks first, and then perform the communication operation when the conditions are met.

The communication process described above can be represented by the following figure. The communicating processors can all access shared memory. Around the shared memory, an interrupt line can be configured in the direction from the main processor to the coprocessor and from the coprocessor to the main processor, namelyInter-Processor Interrupt (IPI), carried by the PPI (Private Peripheral Interrupt) line on STM32MP1. The core interrupt initiator first writes the message data to the shared memory, then raises an inter-processor interrupt. The interrupted core thread reads the shared memory in the interrupt service routine to obtain the data notified by the initiator.

Shared memory and inter-processor interrupt
Shared memory and inter-processor interrupt

Mailbox framework

The Mailbox framework is closely related to IPCC. Mailbox is a driver architecture that depends on the hardware platform for implementation. For example, the Mailbox on the STM32MP157 platform relies on the IPCC peripheral. Its Mailbox framework is shown in the following figure: (Mailbox is a kind of message transmission tool that relies on IPCC at the bottom layer, but IPCC does not transmit data. Based on IPCC, Mailbox can transfer message data.)

Mailbox framework
Mailbox framework

How does the upper-layer application know that data has been completely sent or fully received? This task is left to the Mailbox framework. The implementation of Mailbox is divided into a mailbox controller and a mailbox client:

  • The mailbox controller is mainly responsible for configuring and processing message queues or interrupt requests (IRQ) from the IPCC peripheral, and provides a common API for mailbox clients that send or receive notification messages.

  • The mailbox client is mainly responsible for sending or receiving notification messages. It sends or receives notification messages through the channel provided by the mailbox controller. This channel is the IPCC channel.

Users can define their own mailbox client. As shown in the figure above, the mailbox controller under Linux isstm32_ipcc, which configures and controls the IPCC peripheral and can provide mailbox services.stm32_rprocIt is the remote processor platform driver. It mainly handles platform resources associated with the remote processor (such as registers, watchdog, reset, clock, and memory). It can register corresponding callback functions into the Remoteproc framework, and can also forward notification messages to the remote processor through the mailbox framework.

The general workflow of the mailbox framework is:

  1. First, register the mailbox controller;
  2. Before the mailbox client sends data, it first applies for a channel;
  3. The client sends data;
  4. The mailbox client records the data;
  5. The mailbox controller calls back the data received at the lower layer to the upper-layer application;
  6. When data transmission is complete, the mailbox controller notifies the upper layer that the current data has been sent;
  7. The mailbox client releases the channel.

Regarding the Mailbox framework, in the Linux kernel source codedrivers/mailboxthere are related drivers under the directory.

References

[1]
【STM32MP157 Heterogeneous Core Communication Framework Learning Section】（2）IPCCCommunication framework
Loading comments…