-
Notifications
You must be signed in to change notification settings - Fork 350
readme: add some highlevel detail around the boot flow. #10609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 | ||||||
| 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
|
||||||
| ``` | ||||||
|
|
||||||
| 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. | ||||||
|
||||||
| 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
AI
Mar 9, 2026
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the Mermaid diagram,
pciis used as the participant alias forprimary_core_init. This is easy to misread as the PCI bus/subsystem. Consider renaming the alias to something unambiguous (e.g.,pcore,pc_init, orprimary) to avoid confusion in the rendered diagram.