Sound Open Firmware as a native audio backend for Zephyr

[iuliana-prodan]

Problem Description

Sound Open Firmware (SOF) is already present in Zephyr as a module and can be built as an out of tree application.
It runs on DSPs (such as Cadence HiFi4, HiFi5, etc.), M7 or Cortex A core, using Zephyr as the RTOS.

SOF was originally designed for Linux-based audio stacks, where a high-performance Cortex-A processor running Linux manages firmware loading, pipeline setup, and runtime control of the DSP.

However, many microcontrollers, such as the NXP i.MX RT series, include a DSP cores (e.g., HiFi4) and are used in designs that do not run Linux at all. In these systems, there is currently no standard way to use SOF because:

• The Linux-based host stack is required
• Zephyr currently lacks a host-side audio frontend (for SOF control)
• The SOF IPC protocol and topology management are not natively supported on Cortex-M hosts

This gap prevents adoption of SOF in pure-MCU embedded systems.

This proposal aims to replace the Linux-based host with a Zephyr-based one (for Cortex-M microcontroller at least), enabling complete MCU-class deployments (e.g., i.MX RT600, i.MX RT700) that do not require Linux but can still utilize SOF’s powerful audio processing capabilities on an embedded DSP or secondary Cortex-M core.

Proposed Change (Summary)

Allow a Zephyr-based Cortex-M core to act as a SOF host controller, managing:

• Firmware loading onto the DSP (or another Cortex-M core)
• IPC communication and command handling
• Topology definition and pipeline control

This removes the dependency on a Cortex-A host with Linux and enables fully embedded, real-time audio processing applications on MCUs like the i.MX RT600, RT700 or RT1170.

Proposed Change (Detailed)

To enable Zephyr to act as the host side of SOF, we propose the following:

1. Implement a SOF host driver/subsystem in Zephyr:

• Handles SOF firmware image loading (e.g., from flash) - optional if SOF can run from flash
• Implements the SOF IPC host-side protocol (command encoding, response parsing)

DSP Startup: Who starts the DSP, and how?

The Zephyr-based Cortex-M core (M33 or similar) will be responsible for:

• Copying SOF firmware to the appropriate memory region (ITCM or shared SRAM) - optional
• Setting up the boot vector for the DSP (e.g., HiFi4)
• Releasing the DSP from reset via memory-mapped system control registers

2. IPC Communication Architecture

Host side (M-core running Zephyr) - the new Zephyr audio frontend:

• Acts as the SOF host
• IPC with SOF side for:
  • firmware control, pipeline setup, stream triggers, etc.
  • receives events/notification from SOF side (pipeline events and others)

DSP side (HiFi4 running SOF on Zephyr) does not change:

• Receives and decodes IPC messages from the host
• Executes commands (e.g., start pipeline, process audio)
• Sends responses, status updates, and stream notifications to host

Possible options for IPC mechanism

A. Message Unit (MU):

• Used as the main hardware mechanism for exchanging messages (mailbox-style) between the M33 and HiFi4 cores
• Each core has its own set of MU registers mapped at different addresses
• Messages (commands, triggers, notifications) are exchanged via 32-bit write/read through MU registers
• IRQs are used to notify the other side when a message is available
  and
  Shared SRAM:
• Used as the shared memory region for:
• Audio data buffers
• IPC message payloads (e.g., firmware parameters, pipeline configs)
• The DSP and M33 both access this region directly using known memory addresses

B. ipc_service
Zephyr’s ipc_service API is a high-level abstraction for inter-core communication.
It supports:

• Multiple transports: RPMsg, shared memory, custom backends
• Asynchronous message passing
• Callback-based interfaces

Cons:

• May require extending or adapting to match SOF’s message structure

C. RPMsg
RPMsg is often used for inter-core communication on SoCs with OpenAMP-compatible MCUs.
Zephyr has:

• Native support for RPMsg backend
• Shared memory region configuration via device tree

Whether using ipc_service, raw MU, or RPMsg:

• The message format must conform to SOF IPC v3/v4 structures (defined in SOF headers)
• Shared memory regions should be defined for audio buffers and IPC command payloads
• Interrupts should notify the receiving side of a new message

3. Pipeline and topology management:

The SOF pipeline is defined dynamically by a topology file loaded by the Linux host.

In this Zephyr-hosted model, we propose:

• Static pipeline definition in C (initial phase):
• The host defines the component graph using SOF’s internal IPC structures (sof_ipc_pipe_new, sof_ipc_comp_*, etc.)
• These structures are serialized and sent to the DSP using Zephyr-hosted IPC functions

Pipeline creation flow:

1. M-core initializes shared memory buffers
2. M-core sends pipeline and component setup commands over IPC to the DSP
3. DSP constructs the pipeline internally in SOF
4. M-core sends a SOF_IPC_PIPE_READY and SOF_IPC_STREAM_TRIG_START to begin playback

This flow is similar to the Linux SOF host one.

4. How is a WAV file provided for playback?

To play a WAV file on the DSP:

• WAV file parsing and playback are handled by the Cortex-M Zephyr host.
• The file can be:

• Stored in flash and accessed via filesystem APIs (e.g., fs_open())
• Included in the firmware image for testing

Flow:

1. Host reads the WAV header, extracts format (channels, sample rate, bit depth)
2. Sends SOF_IPC_STREAM_PCM_PARAMS with this format info to DSP
3. Reads and buffers PCM data from the WAV file
4. Uses shared memory to push PCM data to the DSP
5. Triggers processing with SOF_IPC_STREAM_TRIG_START

The host is responsible for:

• Handling buffer underrun/overrun conditions
• Scheduling data writes based on IPC response or buffer status

Nice to have or future improvements:

• Define pipelines via device tree or a Zephyr DSL (domain-specific language)
• Use Kconfig or shell interfaces to select pre-defined pipelines
• Stream audio over UART/BLE/USB
• Provide shell commands or test applications to interact with SOF pipelines at runtime

First steps:
Sample Host Controller Implementation:

• Create a reference implementation for i.MX RT600/RT700 (Cortex-M33 as host, HiFi4 as DSP)
• Demonstrate SOF firmware loading, IPC communication, and playback pipeline control

A proof of concept with a host component as M33 firmware, Zephyr-based was already made by @VitekST - see here and here.
In this SOF-on-RT600 implementation the audio playback is driven by a simplified or hardcoded source of PCM data, primarily for the purpose of validating the SOF port and audio pipeline functionality on the HiFi4 DSP.

[kv2019i]

Thanks @iuliana-prodan for the write-up, this is very interesting! One note on the IPC, @dcpleung has been working on putting SOF IPC on top of a service layer -> #91606 . In a fully Zephyr hosted system, one could just use a simple shared mem based backend for the (IPC service 7eb626a ) and existing SOF app code would work with no change (after 91606 is merged first of course). Update: Forgot to highlight that PR 91606 already works with full SOF stack, see thesofproject/sof#10089

[dbaluta]

@lgirdwood tried to add you as a review, but it looks it only have asignees.

[iuliana-prodan]

@lgirdwood @ranj063 @lyakh @nashif @dleach02 @carlescufi feel free to loop in anyone else who might be interested.