Skip to content

Commit 260bec6

Browse files
committed
readme: add some initial context around developer tools
High level documentation describing developer and debug tooling. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
1 parent 295fc90 commit 260bec6

File tree

6 files changed

+395
-107
lines changed

6 files changed

+395
-107
lines changed

scripts/README.md

Lines changed: 167 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,167 @@
1+
# SOF Helper Scripts
2+
3+
This folder contains a lot of useful scripts that can speed up development for routine tasks or simplify execution of complex tasks.
4+
5+
## Build Scripts
6+
7+
SOF has several build targets depending on whether you are building firmware, tooling, documentation or topologies. This directory has a helper for each.
8+
9+
### Firmware Build (`xtensa-build-zephyr.py`)
10+
11+
Firmware can either be built using west commands directly or by the `xtensa-build-zephyr.py` script. This script wraps up the west commands and can build using either the Zephyr SDK compiler or the Cadence xtensa compiler for xtensa targets.
12+
13+
Please run the script with `--help` to see all options.
14+
15+
E.g to build SOF for Intel Pantherlake:
16+
17+
1) Enable the python virtual environment for west. This should be in your SOF workspace installation directory. Default is `~/work/sof` (only needs run once).
18+
19+
```bash
20+
source ~/work/sof/.venv/bin/activate
21+
```
22+
23+
2) Now run the build script. *Note: most build errors are a result of ingredients being out of sync with the west manifest. Please run `west update` and rebuild before fixing/reporting build errors.*
24+
25+
```bash
26+
./scripts/xtensa-build-zephyr.py -p ptl
27+
```
28+
29+
### Reproducible Output Builds (`test-repro-build.sh`)
30+
31+
This script can be used to locally reproduce the exact build steps and environment of specific CI validation tests.
32+
33+
```bash
34+
./scripts/test-repro-build.sh --help
35+
```
36+
37+
## Tools and Topologies
38+
39+
Tooling and topology can be built together using one script. To build all topologies please run:
40+
41+
```bash
42+
./scripts/build-tools.sh
43+
```
44+
45+
**Options for `build-tools.sh`:**
46+
47+
* `-c` : Rebuild `ctl/` tool
48+
* `-l` : Rebuild `logger/` tool
49+
* `-p` : Rebuild `probes/` tool
50+
* `-T` : Rebuild ALL `topology/` targets
51+
* `-X` : Rebuild topology1 only
52+
* `-Y` : Rebuild topology2 only
53+
* `-t` : Rebuild test topologies
54+
* `-A` : Clone and rebuild the local ALSA git version for `alsa-lib` and `alsa-utils` with latest non-distro features.
55+
* `-C` : No build, only CMake re-configuration. Shows CMake targets.
56+
57+
*Warning: building tools is incremental by default. To build from scratch delete the `tools/build_tools` directory or use `-C`.*
58+
59+
### ALSA Specific Build (`build-alsa-tools.sh`)
60+
61+
If you want to pull down and explicitly recompile only the associated ALSA libraries from their public `alsa-lib` GitHub upstream independently of SOF topologies:
62+
63+
```bash
64+
./scripts/build-alsa-tools.sh
65+
```
66+
67+
## Testbench and Emulation
68+
69+
Testbench is a host application that is used to run SOF processing modules on developers PC. This allows for module development using regular host based tooling.
70+
71+
### Rebuilding the Testbench (`rebuild-testbench.sh`)
72+
73+
This script cleans and rebuilds the host test application binary. Ensure you supply the correct target platform wrapper or fuzzing backend.
74+
75+
**Usage Options:**
76+
77+
* `-p <platform>` : Build testbench binary for `xt-run` for selected platform (e.g. `-p tgl`). When omitted, performs a `BUILD_TYPE=native`, compile-only check.
78+
* `-f` : Build testbench via a compiler provided by a fuzzer (default path: `.../AFL/afl-gcc`).
79+
* `-j` : Number of parallel make jobs (defaults to `nproc`).
80+
81+
### Running the Testbench (`host-testbench.sh`)
82+
83+
Starts the testing sequences. This invokes specific components to ensure basic inputs process without segfaults.
84+
85+
```bash
86+
./scripts/host-testbench.sh
87+
```
88+
89+
### QEMU Check (`qemu-check.sh`)
90+
91+
Automated verifier for executing firmware builds under QEMU emulation.
92+
93+
**Usage:**
94+
95+
```bash
96+
./scripts/qemu-check.sh [platform(s)]
97+
```
98+
99+
* Supported platforms are: `imx8`, `imx8x`, `imx8m`.
100+
* Runs all supported platforms by default if none are provided.
101+
102+
## SDK Support
103+
104+
There is some SDK support in this directory for speeding up or simplifying tasks with multiple steps.
105+
106+
### New Modules (`sdk-create-module.py`)
107+
108+
A new module can be created by running the SDK Create Module script. This python helper copies the SOF template audio module and renames all strings, Cmakefiles, and Kconfigs automatically. It also correctly registers a new DSP UUID and TOML entries.
109+
110+
Please run:
111+
112+
```bash
113+
./scripts/sdk-create-module.py new_module_name
114+
```
115+
116+
## Docker
117+
118+
The docker container provided in `docker_build` sets up a build environment for building Sound Open Firmware. A working docker installation is needed to run the docker build container.
119+
120+
*Note: In order to run docker as non sudo/root user please run:*
121+
122+
```bash
123+
sudo usermod -aG docker your-user-name
124+
```
125+
126+
Then logout and login again.
127+
128+
**Quick Start:**
129+
130+
First, build the docker container. This step needs to be done initially and when the toolchain or ALSA dependencies are updated.
131+
132+
```bash
133+
cd scripts/docker_build
134+
./docker-build.sh
135+
```
136+
137+
After the container is built, it can be used to run the scripts.
138+
139+
To build for tigerlake:
140+
141+
```bash
142+
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh -l tgl
143+
```
144+
145+
or (this command may prompt for a password during rimage installation inside the container)
146+
147+
```bash
148+
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh tgl
149+
```
150+
151+
To rebuild the topology and logger:
152+
153+
```bash
154+
./scripts/docker-run.sh ./scripts/build-tools.sh
155+
```
156+
157+
An incremental `sof.git` build:
158+
159+
```bash
160+
./scripts/docker-run.sh make
161+
```
162+
163+
Or enter a shell:
164+
165+
```bash
166+
./scripts/docker-run.sh bash
167+
```

scripts/Readme.md

Lines changed: 0 additions & 107 deletions
This file was deleted.

src/debug/debug_stream/README.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# SOF Debug Stream
2+
3+
The `debug_stream` framework is an abstract logging and live-data streaming mechanism allowing the DSP to asynchronously push structured or freeform diagnostic records immediately out to the host.
4+
5+
## Feature Overview
6+
7+
Unlike standard tracing (`mtrace`), which requires buffering and complex host parsing logic often tied directly to pipeline topologies or ALSA interfaces, the `debug_stream` bypasses the audio framework entirely. It utilizes the dedicated IPC Memory Windows (specifically the debug slot) to write data.
8+
9+
The stream is particularly useful for reporting:
10+
11+
1. **Thread Information:** Real-time data from Zephyr OS threads (like CPU runtime, context switch frequencies, or stack high-water marks).
12+
2. **Text Messages (`ds_msg`):** Lightweight string prints that bypass the standard heavily-formatted logger.
13+
14+
## How to Enable
15+
16+
These features are disabled by default to save firmware footprint. You can enable them via Kconfig:
17+
18+
* `CONFIG_SOF_DEBUG_STREAM_SLOT=y` : Master switch. Reserves exactly one Memory Window 4k block (default Slot 3) mapping to host space.
19+
* `CONFIG_SOF_DEBUG_STREAM_THREAD_INFO=y` : Activates the Zephyr thread statistics compiler integration (`INIT_STACKS`, `THREAD_MONITOR`).
20+
* `CONFIG_SOF_DEBUG_STREAM_TEXT_MSG=y` : Allows calling `ds_msg("...", ...)` scattered throughout DSP C code to emit plain strings.
21+
22+
## Architecture
23+
24+
The architecture revolves around a "Slot" abstraction where data is copied sequentially over a ringbuffer into the ADSP debug window slot used for the debug stream (mapped over PCIe/SPI for the Host to read non-destructively).
25+
26+
```mermaid
27+
graph TD
28+
subgraph SOF Firmware
29+
SysEvent["System Event / OS Timer"] --> |Triggers| DSThread["Thread Info Collector"]
30+
DevCode["Developer Code"] --> |"ds_msg()"| Text["Text Subsystem"]
31+
32+
DSThread --> Formatter[DS Formatter]
33+
Text --> Formatter
34+
35+
Formatter --> Slot[Memory Window Slot 3]
36+
end
37+
38+
subgraph Host System
39+
PyTool[tools/debug_stream/debug_stream.py]
40+
Slot -.->|PCIe DMA / IPC Memory| PyTool
41+
PyTool --> |Stdout| User[Developer Terminal]
42+
end
43+
```
44+
45+
## Usage Example
46+
47+
If you enable `CONFIG_SOF_DEBUG_STREAM_TEXT_MSG=y`, developers can insert rapid debug markers without setting up topology traces:
48+
49+
```c
50+
#include <user/debug_stream_text_msg.h>
51+
52+
void my_function() {
53+
ds_msg("Reached tricky initialization state! Value: %d", some_val);
54+
}
55+
```
56+
57+
On the host machine, you extract this continuous output stream by running the provided SOF tooling:
58+
59+
```bash
60+
python3 tools/debug_stream/debug_stream.py
61+
```

0 commit comments

Comments
 (0)