Everyone should use deployable builds by default. Don't switch the
default behavior yet but add a --no-deployable-build option in case
anyone is stuck.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The default firmware file path is standardized among vendors as follows:
IPC3
/lib/firmware/VENDOR/sof/
├── community
│ └── sof-PLAT.ri
├── dbgkey
│ └── sof-PLAT.ri
└── sof-PLAT.ri
IPC4
/lib/firmware/VENDOR/sof-ipc4/
└── PLAT
├── community
│ └── sof-PLAT.ri
├── dbgkey
│ └── sof-PLAT.ri
└── sof-PLAT.ri\n
Currently the binaries created by the build can only be used for direct
deployment on IPC3 platforms but if one builds different vendor firmwares
the files have to be manually picked and sorted out.
We have two flags: --fw-naming and --use-platform-subdir which can be
played with but still not going to produce deployable build.
Introduce a new flag: --deployable-build
With the flag specified all other modificators are going to be ignored and
the build will do the 'right thing' to create a directory structure which
can be deployed as it is to the target's firmware directory.
To achieve this several changes needed:
PlatformConfig:
- drop the name member and replace it with a vendor string
- add a flag to indicate IPC4 platforms
Later a new option can be added if needed for platforms which can be
IPC3 or IPC4
Ignore fw-naming and use-platform-subdir in case of deployable build. The
options will be reset to their default in case they are changed.
symlink_or_copy extended to handle relative symlinks when the target and
link is not under the same directory.
The --deployable-build is disabled by default, it has to be enabled to
create deployable build for now.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Print platform alias information to reduce the need for guessing when
trying to figure out what platform supports what platform.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The following aliases are missing:
tgl: adl-n, rpl
tgl-h: rpl-s
mtl: arl
Update the aliases list accordingly.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
This re-adds imx8ulp to --all platform list. This was removed
in commit 7737efadf4 ("xtensa-build-zephyr.py: remove imx8ulp from --all")
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Rename the variable name used by SOF script with the one expected by the
Zephyr build system for simplicity and consistency.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Rename:
- tgl-cavs.toml to tgl.toml
- tgl-h-cavs.toml to tgl-h.toml
Remove the IPC3/IPC4 switch added by commit 6f71808e3e
("xtensa-build-zephyr.py: add ipc4 build support for tgl")
This brings back consistency which is required for the .toml
split (#8490)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This was broken from the start when converting the script from shell
script to Python.
A good reference was left in the non-Zephyr script which is still
active: `./scripts/xtensa-build-all.sh -h`
Fixes initial commit 1de3ef3675 ("Rewritten xtensa-build-zephyr.sh to
python")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
... source it instead.
We still have duplication with xtensa-build-zephyr.py for now but this
gets at least rid of bash duplication.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This adds support for:
./scripts/rebuild-testbench.sh -p lnl
Also clean-up, re-order and add comments to set_xtensa_params.sh
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As of today's Zephyr commit 92fb8b223825, imx8ulp does not compile.
Do not remove any of its data from `xtensa-build-zephyr.py` but exclude
it from --all
Fixes:
```
scripts/xtensa-build-zephyr.py --all
-- Board: nxp_adsp_imx8ulp
No board named 'nxp_adsp_imx8ulp' found.
CMake Error at zephyr/cmake/modules/boards.cmake:167 (message):
Invalid BOARD; see above.
Call Stack (most recent call first):
cmake/modules/zephyr_default.cmake:129 (include)
share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
CMakeLists.txt:5 (find_package)
```
Fixes 61ccb4c8da ("scripts: zephyr: Add support to build sof for
imx8ulp")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Adding all source files in a single, giant zephyr/CMakeLists.txt is
inconvenient and does not scale.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Build for MTL needs other compiler xt-clang, so the COMPILER is
set by default to xt-xcc and changed for MTL in set_xtensa_params.sh
where also core and tools version is defined.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Fixes commit deed9a8808 ("scripts: fuzz: add support for build and
overlays")
The main issue was the way fuzz.sh was trying to parse the overlay
file. Drop that and just pass it as is to `west` and `cmake` instead,
they know what to do with it.
Also:
- Fix invalid syntax in stub_build_all_ipc4.conf
- Make fuzz.sh shellcheck-clean again. Always use shellcheck.
- Temporarily disable `CONFIG_COMP_SMART_AMP` in
stub_build_all_ipc3.conf because `smart_amp.c` does not compile (in
any configuration)
```
sof/src/audio/smart_amp/smart_amp.c:748:9: error:
no member named 'in_channels' in 'struct smart_amp_data'
sad->in_channels = audio_stream_get_channels(&source_buffer->stream);
```
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
It's not clear why `LDFLAGS=-Wl,-LE` was added in
commit 10d0b3b5e1 ("Scripts: Add xt-run build target for
rebuild-testbench.sh"). Maybe it was supposed to be `-Wl,-EL`?
Either way this flag has always been interpreted as adding the directory
`./E/` to the search library path, which obviously never had any
effect; proof below. So it can safely be removed.
Here's the proof:
```
mv ~/XCC/install/builds/RG-2017.8-linux/cavs2x_LX6HiFi3_2017_8/xtensa-elf/lib/libm.a .
./scripts/rebuild-testbench.sh -p tgl
# Fails as expected
# => XCC/install/tools/RG-2017.8-linux/XtensaTools/bin/xt-ld: cannot find -lm
cmake --build tools/testbench/build_xt_testbench/ -- testbench
# Same again
# => XCC/install/tools/RG-2017.8-linux/XtensaTools/bin/xt-ld: cannot find -lm
mkdir tools/testbench/build_xt_testbench/E/
cp libm.a tools/testbench/build_xt_testbench/E/
cmake --build tools/testbench/build_xt_testbench/ -- testbench
# => now compiles!
```
Remember: the best way to test software is always to break it.
Don't forget to fix XCC:
```
mv libm.a ~/XCC/install/builds/RG-2017.8-linux/cavs2x_LX6HiFi3_2017_8/xtensa-elf/lib/
```
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
For legacy CAVS platforms (TGL/ADL/EHL), the default
build config is IPC4 now, and the overlay file is
already emptied. Remove the option in this build
script.
Signed-off-by: Chao Song <chao.song@linux.intel.com>
The script runs the unit tests natively as gcc compiled. The
tgph_defconfig is no more available, so use another configuration
that is available in src/arch/xtensa/configs.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Add support to specify an overlay file to use with the fuzz script and
another flag to build without fuzzing
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
This restores parity with the installer/GNUmakefile in the stable-v2.2
branch and simplifies CI deployment.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Don't rely on some semi-random default value.
The final `zephyr/.config` and binaries are strictly identical.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
We used to provide the `default_rimage_key` in two places:
1) as a default `RIMAGE_KEY` attribute (newer `otc_private_key_3k`)
2) as an explicit `else` clause that was never run because of 1) (older
`otc_private_key`)
Remove the redundant `else` clause in 2); it became dead code. This
simplifies the code and makes the script ready for the day when the key
argument will be optional for rimage (more about this in
https://github.com/zephyrproject-rtos/zephyr/pull/58356)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fixes commit a769d3941d ("xtensa-build-zephyr.py: stop calling west
sign, rely on west build")
Before that commit, `xtensa-build-zephyr.py` used to invoke `west sign`
directly and in the same current directory. This allowed relative key
paths to just work. Now that `west sign` is indirectly invoked by `west
build`, there is no possible way to make relative key paths work. So we
must resolve them before using them.
Fixes#7718
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Stop invoking west sign manually. Configure rimage using `west config`
and a platform-specific WEST_CONFIG_LOCAL file instead, then rely on
west build to invoke rimage.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Do not make the switch yet. Make the switch in a smaller commit that can
more easily be reverted in case of a bug or some missed dependency
somewhere.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Marc Herbert