Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
156 changes: 156 additions & 0 deletions src/init/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
# DSP Initialization (`src/init`)

The `src/init` directory contains the generic digital signal processor (DSP) initialization code and firmware metadata structures for Sound Open Firmware (SOF). It acts as the bridge between the underlying RTOS (Zephyr) boot phase and the SOF-specific task scheduling and processing pipelines.

## Architecture and Boot Flow

The firmware initialization architecture relies on the Zephyr RTOS boot sequence. Zephyr handles the very early hardware setup and kernel initialization before invoking SOF-specific routines via Zephyr's `SYS_INIT` macros.

### Primary Core Boot Sequence

The primary entry point for SOF system initialization is `sof_init()`, registered to run at Zephyr's `POST_KERNEL` initialization level. This ensures basic OS primitives (like memory allocators and threads) are available before SOF starts.

`sof_init()` delegates to `primary_core_init()`, which executes the following sequence:

```mermaid
sequenceDiagram
participant Zephyr as Zephyr RTOS
participant sof_init as sof_init (src/init.c)
participant pci as primary_core_init
Comment on lines +18 to +19
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the Mermaid diagram, pci is used as the participant alias for primary_core_init. This is easy to misread as the PCI bus/subsystem. Consider renaming the alias to something unambiguous (e.g., pcore, pc_init, or primary) to avoid confusion in the rendered diagram.

Copilot uses AI. Check for mistakes.
participant trace as trace_init
participant notify as init_system_notify
participant pm as pm_runtime_init
participant platform as platform_init
participant ams as ams_init
participant mbox as mailbox (IPC4)
participant task as task_main_start

Zephyr->>sof_init: SYS_INIT (POST_KERNEL)
sof_init->>pci: Initialize Primary Core Context

pci->>trace: Setup DMA Tracing & Logging
pci->>notify: Setup System Notifiers
pci->>pm: Initialize Runtime Power Management

pci->>platform: Platform-Specific HW Config
note right of platform: e.g., interrupts, IPC windows (Intel, i.MX)

pci->>ams: Init Asynchronous Messaging Service

pci->>mbox: Set Firmware Registers ABI Version

pci->>task: Start SOF Main Processing Task Loop
Comment on lines +28 to +42
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the Mermaid diagram, pci is used as the participant alias for primary_core_init. This is easy to misread as the PCI bus/subsystem. Consider renaming the alias to something unambiguous (e.g., pcore, pc_init, or primary) to avoid confusion in the rendered diagram.

Copilot uses AI. Check for mistakes.
```

1. **Context Initialization**: Sets up the global `struct sof` context.
2. **Logging and Tracing**: Initializes Zephyr's logging timestamps and SOF's DMA trace infrastructure (`trace_init()`), printing the firmware version and ABI banner.
3. **System Subsystems**:
- Initializes the system notifier (`init_system_notify()`) for inter-component messaging.
- Sets up runtime power management (`pm_runtime_init()`).
4. **Platform-Specific Initialization**: Calls `platform_init()` to allow the specific hardware platform (e.g., Intel cAVS, IMX) to configure its hardware IPs, interrupts, and IPC mailbox memory windows.
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Platform naming is inconsistent: earlier the note uses i.MX, while this line uses IMX. Please standardize the spelling/capitalization (e.g., i.MX) so readers don’t assume these refer to different platforms.

Suggested change
4. **Platform-Specific Initialization**: Calls `platform_init()` to allow the specific hardware platform (e.g., Intel cAVS, IMX) to configure its hardware IPs, interrupts, and IPC mailbox memory windows.
4. **Platform-Specific Initialization**: Calls `platform_init()` to allow the specific hardware platform (e.g., Intel cAVS, i.MX) to configure its hardware IPs, interrupts, and IPC mailbox memory windows.

Copilot uses AI. Check for mistakes.
5. **Architectural Handoff**: For IPC4, it sets the Firmware Registers ABI version in the mailbox. It may also unpack boot manifests if configured.
6. **Task Scheduler**: Finally, it calls `task_main_start()` to kick off the main SOF processing task loop.

### Secondary Core Boot Sequence

For multi-core DSP platforms, secondary cores execute `secondary_core_init()`:

```mermaid
sequenceDiagram
participant ZephyrN as Zephyr RTOS (Core N)
participant sci as secondary_core_init
participant check as check_restore
participant notify as init_system_notify
participant ll as scheduler_init_ll
participant dp as scheduler_dp_init
participant idc as idc_init

ZephyrN->>sci: Core Wake/Boot
sci->>check: Cold boot or power restore?

alt is Power Restore (e.g. D0ix wake)
sci->>sci: secondary_core_restore()<br>(Skip full init)
else is Cold Boot
sci->>notify: Setup Local Core Notifiers

sci->>ll: Init Low-Latency (LL) Timer Domain
sci->>ll: Init LL DMA Domain (if applicable)
sci->>dp: Init Data Processing (DP) Scheduler

sci->>idc: Init Inter-Domain Communication (IDC)
end
```

1. **Power State Checking**: It checks if the core is cold booting or waking up from a low-power restore state (e.g., D0ix) via `check_restore()`. If returning from power off, it restores state without re-allocating core structures.
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence mixes 'low-power restore' (e.g., D0ix) with 'returning from power off', which can be interpreted as a full power-gate/reset scenario. Consider clarifying the exact condition check_restore() covers (retention/restore vs full power-off) so the restore path description is not contradictory.

Suggested change
1. **Power State Checking**: It checks if the core is cold booting or waking up from a low-power restore state (e.g., D0ix) via `check_restore()`. If returning from power off, it restores state without re-allocating core structures.
1. **Power State Checking**: It checks if the core is cold booting or resuming from a low-power retention/restore state (e.g., D0ix) via `check_restore()`. In the restore case, it restores state without re-allocating core structures; in the cold-boot case, it follows the full initialization path described below.

Copilot uses AI. Check for mistakes.
2. **Local Subsystem Setup**: Sets up system notifiers for the local core.
3. **Scheduler Setup**: Initializes the Low-Latency (LL) and Data Processing (DP) schedulers on the secondary core.
4. **Inter-Core Communication**: Initializes the Inter-Domain Communication (IDC) mechanism (`idc_init()`), allowing cross-core messaging.

### Firmware Extended Manifest (`ext_manifest.c`)

This directory also provides the extended manifest implementation. The manifest consists of structured metadata embedded into the `.fw_metadata` section of the firmware binary.

```mermaid
classDiagram
direction LR

class fw_metadata {
<<Section>>
+ext_man_fw_ver
+ext_man_cc_ver
+ext_man_probe
+ext_man_dbg_info
+ext_man_config
}

class ext_man_elem_header {
+uint32_t type
+uint32_t elem_size
}

class ext_man_fw_version {
+ext_man_elem_header hdr
+sof_ipc_fw_version version
+uint32_t flags
}

class ext_man_cc_version {
+ext_man_elem_header hdr
+sof_ipc_cc_version cc_version
}

class ext_man_probe_support {
+ext_man_elem_header hdr
+sof_ipc_probe_support probe
}

class ext_man_dbg_abi {
+ext_man_elem_header hdr
+sof_ipc_user_abi_version dbg_abi
}

class ext_man_config_data {
+ext_man_elem_header hdr
+config_elem elems[]
}

fw_metadata *-- ext_man_fw_version
fw_metadata *-- ext_man_cc_version
fw_metadata *-- ext_man_probe_support
fw_metadata *-- ext_man_dbg_abi
fw_metadata *-- ext_man_config_data

ext_man_fw_version *-- ext_man_elem_header
ext_man_cc_version *-- ext_man_elem_header
ext_man_probe_support *-- ext_man_elem_header
ext_man_dbg_abi *-- ext_man_elem_header
ext_man_config_data *-- ext_man_elem_header
```

When the host OS (e.g., Linux SOF driver) parses the firmware binary before loading it, it reads these manifest structures to discover firmware capabilities dynamically. The manifest includes:

- **Firmware Version**: Major, minor, micro, tag, and build hashes (`ext_man_fw_ver`).
- **Compiler Version**: Details of the toolchain used to compile the firmware (`ext_man_cc_ver`).
- **Probe Info**: Extraction probe configurations and limits (`ext_man_probe`).
- **Debug ABI**: Supported debugger ABI versions (`ext_man_dbg_info`).
- **Configuration Dictionary**: Compile-time enabled features and sizing parameters (e.g., `SOF_IPC_MSG_MAX_SIZE`).
Loading