-
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
Open
lgirdwood
wants to merge
3
commits into
thesofproject:main
Choose a base branch
from
lgirdwood:readme-init
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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, i.MX) to configure its hardware IPs, interrupts, and IPC mailbox memory windows. | ||
| 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 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. | ||
| 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`). | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.