readme: add some highlevel detail around the boot flow.#10609
readme: add some highlevel detail around the boot flow.#10609lgirdwood wants to merge 1 commit intothesofproject:mainfrom
Conversation
Describe the boot flow and manifest. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
lgirdwood
requested review from
dbaluta,
kv2019i,
lbetlej,
mmaka1 and
plbossart
as code owners
There was a problem hiding this comment.
Pull request overview
Adds high-level documentation for src/init describing the SOF firmware boot flow (primary/secondary cores) and the extended firmware manifest layout.
Changes:
- Documented primary core boot sequence, including initialization ordering and key subsystems
- Documented secondary core boot sequence for cold boot vs restore paths
- Added an overview of the extended manifest structure embedded in
.fw_metadata
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| participant sof_init as sof_init (src/init.c) | ||
| participant pci as primary_core_init |
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
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.
| 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. |
| 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. |
There was a problem hiding this comment.
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. |
Describe the boot flow and manifest.