In order to support AMD as part of the docker image and CI we need to
include it in the build list as the overlays are already added to the
overlay repo.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
"tree" is very useful but it's not critical, not worth failing the build
for.
Also remove a single quote from the help message as it breaks parsing
in one simple editor I use (jed) and possibly others.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Without CMP0079 we cannot conditionally include libraries against SOF in
sub directories without seriously restructuring the project. This is
because the old policy requires the link target must be created in the
same folder. This does not work well from a configuration standpoint for
3P audio libraries trying to keep their config in src/audio/*. Rather
than enable the policy, lets simply upgrade since 3.13 is widely
available.
With this upgrade we can also remove the two version dependent checks at
the top of our scripts.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
This is needed by CI to clone only once and then take control of the
iteration over platform builds. CI already does all that but by
copy/paste/diverge of this clone() function.
Once cloning Zephyr in CI code is de-duplicated and uses this new
clone-only feature instead, it will be possible to submit any Zephyr
commit to SOF testing. In other words it will make failed attempt
https://github.com/thesofproject/sof/pull/4728 possible
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
main() was growing too big. Zero functional change.
Also rename the too generic "build()" to build_all()
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Recently merged rework of multicore support in Zephyr has
broken builds with XCC. Disable XCC based builds in CI until
issue is resolved in Zephyr mainline. Issue tracked as:
https://github.com/zephyrproject-rtos/zephyr/issues/38349
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
We care about other build errors more.
This also makes it easier to test locally that "west build" does not
depend on rimage to create zephyr.elf
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This is motivated by the zephyr.elf build that does not need rimage at
all.
Also build smex later, only when it's needed.
After building and deleting the rimage/ clone, a plain SOF clean +
RE-build now fails much later: it now fails AFTER successfully building
the sof binary, only when it tries to build either bootloader,
boot_module or base_module that actually need rimage:
[ 87%] Performing configure step for 'rimage_ep'
CMake Error: The source directory "/home/SOF/sof/rimage" does not appear
to contain CMakeLists.txt.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The BSS usage exceeds available memory when building for
APL/cavs15 hardware with XCC, so disable it for now. Issue
tracked as https://github.com/thesofproject/sof/issues/4645
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Remove the unnecessary assumption that Xtensa tools are installed under
'XtDevTools'.
Align indentation to use tabs as is used elsewhere in this file.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Add support to build with XCC compiler by setting XTENSA_TOOLS_ROOT
env variable. The interface follows xtensa-build-all.sh, so existing
CI scripts for SOF builds can easily update to build with XCC.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Add imx8 platform for local testing.
TODO: Update xtensa-build-zephyr.sh when Zephyr repo
is updated with imx8 support.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Adds --error-exitcode=1 to valgrind options (otherwise what's the point
of using valgrind?)
Skip alloc test that does not pass on HOST (passes with xt-run)
Add help message.
Runnable from anywhere.
Use shell functions
https://github.com/thesofproject/sof-test/issues/740
Fix all quoting issues and other shellcheck warnings.
Add comments.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Link to the CMake section in sof-docs which documents a lot of what this
script does and is probably out of date now. It would be less out of
date if this link had been there and more people had been aware that
this documentation even existed.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Thanks Ranjani for finding most of these magic values.
Also move READY_MSG closer to the only place where it's used so it does
not look like a "global" anymore.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
-p is required when the real (not symbolic) directories are not nested
in one another.
The documentation gap was clearly demonstrated by me getting confused
even though _I_ implemented this logic some time back.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Ready to be transferred to the remote system. Sample output:
build-sof-staging
├── sof
│ ├── community
│ │ ├── sof-apl.ri
│ │ └── sof-tgl-h.ri
│ ├── sof-apl.ldc
│ └── sof-tgl-h.ldc
└── tools
└── sof-logger
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This enables support for running the allocator mocks with valgrind by
building the allocator for the host library target using a similar
heap map to Intel CAVS targets (memory.c is almost identical copy of CAVS
version).
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Zephyr's incremental build works and saves time. I have been using it
with SOF for a long time. Slowly rebuilding from scratch is as simple as
deleting the build-$platform/ build directory. Quickly building not from
scratch is not possible without this commit.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Zero functional change.
Makes the code and the build logs clearer, especially for SOF people new
to west. Short options are for saving repetitive typing; no reason to
use them in a script.
Also show the real /bin/pwd which can help when west gets lost in
complex symbolic link situations.
https://github.com/zephyrproject-rtos/west/issues/419
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Catching up latest LTS Ubuntu image, 20.04. It is supposed to be minor
upgrade but alsa-lib need to be set default library path,
/usr/lib/x86_64-linux-gnu/. Otherwise topology library loading error
is found for SOF tool build. This is typical error message,
alsatplg: error while loading shared libraries: libatopology.so.2:
cannot open shared object file: No such file or directory.
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
There was a assumption /etc/apt/apt.conf has apt proxy settings for
the system. This workaround is not required.
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
More robust support for "manual" installations.
Also rephrase usage string to remove a single quote breaking
the shell parser in one editor I use (sorry).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
By default, the Zephyr build does not log its version. The fix has
already been submitted at
https://github.com/zephyrproject-rtos/zephyr/pull/34842 however:
- 34842 may take some time. Zephyr reviewers are even busier than the
SOF reviewer.
- 34842 could even be rejected
- 34842 will at best log the SHA1 and no context. This is more verbose
and future-proof because it supports more complex situations like
testing a pull/12345/merge
As seen in (unrelated) PR #4123, we need Zephyr git versions NOW.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fixes 33c5f5d38e ("xtensa-build-zephyr: do not clone a second version of
sof.git")
The very first version of this test was checking whether the rimage/
directory exists, which proves nothing. So I switched to
rimage/CMakelists.txt but forgot change the `test` flag.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This script lives in a sof.git/ clone yet it was systematically cloning
a second sof.git/. Besides the obvious confusion and risk of editing the
wrong files, this meant it was not possible to build code that has not
been merged yet! This was a problem for both CI and developers. Fixed by
using symbolic links to ourselves instead.
Note it is _still_ possible to build from another sof.git clone if
desired, however this script will never git re-clone a second sof.git
itself, that second clone has to be created (e.g.: by west) before this
script runs.
When cloning a brand new zephyrproject, use a shallow zephyr clone and
download only the two zephyr modules we actually use. This speeds up
automation considerably and makes it much faster for non-Zephyr
developers to reproduce Zephyr issues. Developers can always git
unshallow and west update once if they want to.
Rename the default west top to "zephyrproject" to not just match the
zephyr documentation but to also avoid creating a double zephyr/zephyr/
directory.
See the new print_usage() for a few more implementation details.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
It still looks smart but the \n addition compared to the original
version in xtensa-build-all.sh broke it for more advanced cases:
die '%s %d' str 5
-bash ERROR: -bash: printf: 5\n: invalid number
As reported by shellcheck. shellcheck saves lives.
In scripts/xtensa-build-zephyr.sh line 22:
>&2 printf "$@\n"
^-- SC2145: Argument mixes string and array.
Use * or separate argument.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
... because the latter does not print on stderr when not found; so IDEs
and CIs don't display this as a warning.
Also remove the "... and ignore set -e" comment that made sense at the
time of commit cad86dc340 ("scripts: xtensa-build: fix alias detection
for bxt/apl gcc") but not anymore.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Allows the mocks to be quickly run on the host with full access to host
debug and development tooling.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
In an ideal world, every CI engine records and shares the most important
CI information:
- current date and time in a well identified timezone
- git version of the pull request
- git version of the moving branch the PR is being merged with
In the real world we have multiple CI solutions and they unfortunately
cannot not all be trusted to perform their most basic job
correctly. Fortunately, they all make at least build logs available so
these very few lines of code adding very few lines of output cost near
zero extra build time and solve the problem once for all. I feel stupid
I didn't do this sooner, this would have saved me hours and hours in
vain requests and discussions and in trying to puzzle that information
together.
Sample output:
-- Preparing Xtensa toolchain
version.cmake starting SOF build at 2021-03-31T18:09:46Z UTC
Building git commit with parent(s):
150fd1e4c968 4249bdb1b305 [other parent if merge] (HEAD -> main) cmake: ...
-- GIT_TAG / GIT_LOG_HASH : v1.7-rc1-174-g150fd1e4c968-dirty / 150fd1e4c968
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Curtis Malainey