Skip to content
Merged
Show file tree
Hide file tree
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
34 changes: 0 additions & 34 deletions scripts/README.docker

This file was deleted.

107 changes: 107 additions & 0 deletions scripts/Readme.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,107 @@
# SOF Helper Scripts

This folder contains a lot of useful scripts that can speed up development for routine tasks or simplify execution of complex tasks.

## Build Scripts

SOF has several build targets depending on whether you are building firmware, tooling, documentation or topologies. This directory has a helper for each.

### Firmware

Firmware can either be built using west command 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.

Please run the script with --help to see all options.

E.g to build SOF for Intel Pantherlake:

1) Enable the python virtual environment for west. This should be in your SOF workspace installation direction. Default is ```~/work/sof``` (only needs run once).
```bash
source ~/work/sof/.venv/bin/activate
```
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.*
```bash
./scripts/xtensa-build-zephyr.py -p ptl
```

### Testbench

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.

Please run
```bash
./rebuild-testbench.sh --help
```
for full options.

Testbench can be also be built for Cadence simulator targets.

### Tools and Topologies

Tooling and topology can be built together using one script. To build all topologies please run:

```bash
./scripts/build-tools.sh
```

This script can build:
1) sof-ctl
2) sof-logger
3) probes
4) all topology 1 & 2 and test topologies.
5) Local ALSA git version for alsa-lib and alsa-utils that have features not yet in distro version of ALSA packages.

## SDK Support

There is some SDK support in this directory for speeding up or simplifying tasks with multiple steps.

### New Modules

A new module can be created by running the sdk-create-module script. This script will copy the template module and rename all strings, Cmakefiles, Kconfigs to match the new module. It will also create a UUID for the new module and a TOML manifest entry (for targets that need this).

Please run
```bash
./sdk-create-module.py new_module_name
```

## Docker

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.

Note: In order to run docker as non sudo/root user please run.
```bash
sudo usermod -aG docker your-user-name
```
Then logout and login again.

Quick Start:

First, build the docker container. This step needs to be done initially and
when the toolchain or alsa dependencies are updated.
```bash
cd scripts/docker_build
./docker-build.sh
```
After the container is built, it can be used to run the scripts.

To build for tigerlake:
```bash
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh -l tgl
```
or (may need password test0000 for rimage install)
```bash
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh tgl
```
To rebuild the topology and logger:
```bash
./scripts/docker-run.sh ./scripts/build-tools.sh
```
An incremental sof.git build:
```bash
./scripts/docker-run.sh make
```
Or enter a shell:
```bash
./scripts/docker-run.sh bash
```
1 change: 1 addition & 0 deletions scripts/gen-uuid-reg.py
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,7 @@ def main():
all_uuids.add(uu)
all_syms.add(sym)
emit_uuid_rec(uu, sym)
print(f"Added UUID {uu} with symbol {sym}")
Copy link

Copilot AI Sep 9, 2025

Choose a reason for hiding this comment

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

Debug print statements should not be left in production code. This print statement should be removed or wrapped in a debug flag check.

Copilot uses AI. Check for mistakes.
Copy link
Member Author

Choose a reason for hiding this comment

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

Intentional to show module UUID is being compiled.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This print statement adds unnecessary noise to the logs. If someone needs to inspect the UUIDs, they can easily find them in the uuid-registry.txt file, so logging each one during generation isn't really needed.

Copy link
Member Author

Choose a reason for hiding this comment

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

The logging makes it more obvious to the module developer (most of whom will not know about UUIDs) which UUIDs are being added to the build. i.e. 3P developer can see their new module UUID is either in the build or not as they will see volume, mixin etc UUIDs and realize more quickly I need to add my UUID.


with open(sys.argv[2], "w") as f:
f.write(header)
Expand Down
Loading
Loading