The next step is to find how to extract the (too many?) errors.
In the mean time this already makes sure the build process never bitrots
and that it will always possible to use sparse. It also "documents" how
to use sparse: just copy/paste the commands run by CI.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Added new mtl platform to xtensa-build-zephyr.py.
Added ace directories to cmake files.
Added ACE to kconfig.
Add Meteorlake platform to be built with Zephyr under
CONFIG_ACE_VERSION_1_5 flag.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
This reverts commit e29572bb2d.
The Zephyr SDK 0.15.0 was exceptionally backwards-incompatible, which
meant the docker image could not have it ahead of time as usual, which
caused some CI failures. More details in
https://github.com/zephyrproject-rtos/zephyr/pull/49496
These CI failures were not a bug, they were a "feature": they drew our
attention to how unusual 0.15.0 was and they let us inform developers
before they hit the issue. Continuous Integration at its best; we want
more of that.
Before this unusual 0.15.0 event we had been using "latest" for many
months without any issue.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Recommendation from Zephyr infrastructure is to use a specific
version of the docker-image. This time we need this to upgrade
to SDK 0.15, which is a requirement to use latest main of
Zephyr. The current "latest" tag does not have 0.15 SDK.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Ubuntu 22.04 has ALSA 1.2.6 without ASRC failure #2543
Building in the container is much slower and updating the container is
also very time-consuming. Must be used only when really required.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
No functional change, this is a pure re-ordering of the matrix
parameters to put the shorter ones first which helps see more in narrow
columns like when looking as build logs on github.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
It's faster like this and we also want platform-specific failures to be
identify as such and not block compilation of other platforms.
Also removed obsolete comment that sneaked in previous commit by
mistake and remove duplicate "zephyr" in the job name.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Removed old flags from python script call and replaced with
new one. Added one more working directory to zephyr-build container
now SOF is placed in /workdir/sof and west workspace in /workdir .
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
This should upgrade doxygen from version 1.8.17 to 1.9.1
This will hopefully provide FAIL_ON_WARNINGS and fix issues like
https://github.com/doxygen/doxygen/issues/7970
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
From time to time sof-docs regressions are introduced in sof.git. This
introduces a random and sometimes long delay between when the regression
is introduced and when it is found. A recent example is
https://github.com/thesofproject/sof/pull/5731#issuecomment-1175630147
where the doxygen comments were duplicated. Doxygen alone did not mind,
then the sof-docs build failed much later which took multiple people a
lot of time to understand and bisect.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This makes the difference between "strict" and regular failures very
clear.
Stopping after non-strict failures is misleading, it can give the wrong
impression that there are very few warnings left.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This will make sure platforms without an open-source toolchain available
are added to SUPPORTED_PLATFORMS and do not break the -a option
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
When the build fails we don't want to waste time wondering whether TGL
is affected or not. Other, unsupported platforms are only providing some
nice to have "randconfig" coverage (#5364), they're not important.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
These are Github Actions, so let's use the Github server to increase
performance and reduce external dependencies.
According to https://github.com/zephyrproject-rtos/docker-image there is
no primary or secondary server for that image, they're both equivalent.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Add all platforms that can currently be built with IPC4:
cnl icl jsl tgl tgl-h
Can be adjusted any time later with a one-line change.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Building in parallel is much faster but it makes logs unreadable and
build failures impossible to understand. This is especially true when
building with recent ALSA that produces of deprecation warnings.
To show what actually fails, try to build again with a single thread.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This is a logical revert of eb45907
Based on recently merged #4941, C99 comments are now OK. I never found
any rationale or even written down coding style for excluding them in
the first place.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
With the backported patch to checkpatch.pl the dictionary.txt location
should automagically found and no need to specify it by hand.
Suggested-by: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Tired of fixing Zephyr breakages all the time (latest in
https://github.com/zephyrproject-rtos/zephyr/pull/38733)
Also unhardcode ZEPHYR_SDK_INSTALL_DIR thanks to the previous commit.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The upstream zephyr adds new SDK requirement for APL,
upgrade zephyr SDK version to 0.13.1 for APL build.
Signed-off-by: Chao Song <chao.song@linux.intel.com>
The run with valgrind will error if memory leaks are detected.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Because it's not needed.
Also add a comment explaining why it's still needed to build topologies
so we can remove it some day and test much faster.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Because we can. This would have caught this regression from
commit 287a5f9a2b ("ssp: mclk/bclk turned off unexpectedly")
-DEXTRA_CFLAGS is not very well documented but it is what Zephyr uses,
try `git -C zephyr grep -C 5 EXTRA_CFLAGS and see.
```
sof/src/drivers/intel/ssp/ssp.c: In function 'ssp_set_config_tplg':
sof/zephyr/include/sof/trace/trace.h:44:11: warning:
too many arguments for format [-Wformat-extra-args]
44 | printk("%llu: " format "\n", platform_timer_get(NULL), \
| ^~~~~~~~
...
sof/src/drivers/intel/ssp/ssp.c:763:4: note: in expansion of macro 'dai_info'
763 | dai_info(dai, "ssp_set_config(): hw_free stage:
ignore since there is still user", dai->index);
```
Using -Werror only in CI avoids slowing down developers with temporary
warnings they intend on fixing later (but before submission)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The latest zephyr requires CMake version >= 3.20,
we have to update the docker image to meet the
requirement.
Signed-off-by: Chao Song <chao.song@linux.intel.com>
The recent zephyr code add restriction to the SDK,
and requires the SDK version >= 0.13, we have to
update the docker image for zephyr SOF building.
As the default SDK version in docker image 0.18.1
is still 0.12.4, and the alternative SDK is 0.13.0,
we need to specify the SDK location with env.
Signed-off-by: Chao Song <chao.song@linux.intel.com>
We used to do this in Travis, see commit 7072eb4447 ("travis: run
build-tools.sh with CMAKE_BUILD_TYPE=Release") and older.
Related to issue #4141 build-tools.sh -T does not build development
topologies.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
... because it has definitely helped reproduce compilation issues in the
past in just two lines without going through the whole setup process,
see a list of examples in #4126.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Lets not trust that everyone remembers to lint themselves or that they
fetch the repo in order to execute their job.
Also rename workflow file to be a bit more generic
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Marc Herbert