
- Map the mailbox hardware (configured by the RTSS mailbox driver) into
/dev/sail/*channels. - Offer notification APIs for HLOS applications.
- Allow full duplex, structured IPC between Linux and RTSS/NHLOS over the mailbox IPC mechanism.
- Open channel: Application opens Tx and Rx device nodes exposed by the mailbox resource manager.
- Send: Application writes a structured message to the Tx device node.
- Receive:
- Application blocks (or uses poll()/select()) on the Rx device node.
- Reads messages when notified (async or poll based).
- Close: Application closes the mailbox handles; resource manager cleans up context.
sources/sail-mailbox/sail-mb-umd/include/sail_mailbox.hsources/sail-mailbox/sail-mb-umd/src/sail_mbox_core.c,sail_mbox_lib.c,sail_mbox_lib.h, andsailmb_internal.c
- Carves the shared DDR mailbox region into multiple regions such as region 0, region 1, and region 2.
- Treats each region as a channel/subregion identified by a unique channel/subregion IDN.
- Provides the buffering and notification infrastructure for message passing between RTSS and APSS.
/dev/sail/* nodes.
Message flow and notifications:
- RTSS and APSS share DDR mailbox regions managed by mailbox external driver (RTSS side) and the corresponding APSS/HLOS drivers.
- When APSS or RTSS writes data into a region’s circular buffer, that data becomes available to the application.
- To notify the application that new data is available or that a buffer has been consumed:
The mailbox external driver uses an IPCC to generate asynchronous events between APSS and RTSS.
- On RTSS:
- These IPC events trigger the mailbox external driver callbacks.
- Typical RTOS IPC mechanisms are used to wake up or synchronize tasks that consume/produce messages in real time.
sail_proc/BSP/mailboxExt/public/mailboxExt_api.hsail_proc/BSP/mailboxExt/src/mailboxExt_api.c,mailboxExt_config.c
Create a new mailbox channel
On RTSS side- Add client ID.
- Add the new client ID to
xMailboxExtclienttypeinmailboxExt_api.h. - Place the entry between the QCMI start and end markers:
- Add the new client ID to
- Add channel IDs.
mailboxEBChanType_e in mailboxExt_config.h.
b. Insert the IDs within the QCMI start and end markers:
- Update subregion count.
mailboxEB_QCMI_NUMSUBREGION in mailboxExt_config.h to reflect the new channel:
- For an Rx-Tx pair, the number of subregions is 2, so set
mailboxEB_QCMI_NUMSUBREGIONto 22. - For Rx or Tx only, the number of subregions is 1, so set
mailboxEB_QCMI_NUMSUBREGIONto 21.
- Define a new channel configuration entry.
mailboxEB_DATA static resource table:
xMailboxExtClientType enum.
Structure definition of mbsub_rgn_config_t:
mailboxExt_config.c file for examples of existing channel configurations.
The MAILBOX_CONSOLE entry with index value 3 in the xMailboxExtClientType enum is defined as follows:
Note
- The
namefield should have three characters, with suffix0for read and1for write channels. - If a single Rx or Tx ID is mapped to the
xMailboxExtClientTypeclient entry, initialize other channel entries with default values, seeMAILBOX_CONSOLEexample
-
Add entry in
xMailboxClientRectable. a. Update themailboxEB_CONSTtable:
xMailboxEBClientRec_t:
xMailboxEBChanRec_t:
/dev/sail/log channel, the client with MAILBOX_CONSOLE client ID contains the following configuration entries, where only the Tx (write) channel is defined.
- Select the protocol, sender, and receiver according to the table.
- RTSS cores use logical number suffixes appended to macros, for example, IPCC_C_SAIL0 for core 0.
- The sender column indicates the sender client line used by APSS to link with the RTSS domain receiver client. Each sender client provides the number of signals specified in the table based on protocol selection.
mailbox_test application is location at sail_proc\BSP\tests\sailsw1\mailbox_test\src\MBtests_sailsw1.c.
On APPS side
-
Add a new channel entry in the devicetree.
- Update the devicetree with the new channel configuration:
Note&ipcc_computeL1 IPCC_CLIENT_SAIL0 0xAindicates:ipcc_computeL1: Protocol name (currently only this is supported).IPCC_CLIENT_SAIL1: RTSS core number.0XA: Channel number.
- Example mapping:
This corresponds to the
/dev/sail/log, mapped toMAILBOX_CONSOLEwith index value 3 in thexMailboxExtClientTypeenum.
saildbg-
Location
sail-mailbox/reference_apps/sail_dbg/src/saildbg.c -
Key APIs:
open_sail_mailbox(): Opens the mailbox channel for TX and RX.write_sail_mailbox(): Writes a message to the TX channel.read_sail_mailbox(): Reads a message from the RX channel.close_sail_mailbox(): Closes the mailbox channel for TX and RX.
-
Structures:
struct SailClientDataType *pTxClientData: TX structure for transmitting messages.struct SailClientDataType *pRxClientData: RX structure for receiving messages.
- Mailbox test application: Mailbox test application: saildbg
-
Location
- sail_console_chan`:
-
Location:
sail-mailbox/unit_test_apps/sail_console_chan_app.c - Mailbox test application: Mailbox test application: sail_console_chan_app
-
Location:
RTSS mailbox demo application
Thesailmb_demo reference application demonstrates bidirectional mailbox communication between the APSS, which runs Linux, and RTSS, which runs Free RTOS. The application sends a message from APSS to an RTSS CPU core and receives a response from that RTSS CPU core.
A successful message exchange verifies the following:
- The RTSS firmware has initialized the shared mailbox structure in DDR.
- The Linux mailbox driver has loaded, mapped the shared memory, and completed the hardware handshake with RTSS.
- The APSS application can write a message to shared memory and trigger an interrupt to RTSS.
- RTSS can receive the interrupt, read the message, write a response, and trigger an interrupt to APSS.
- APSS can receive the interrupt, read the response, and display it on the console.
To run the RTSS mailbox demo application, see Mailbox test application: sailmb_demo.

