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>
Even though "latest" is being referenced by the current
https://github.com/zephyrproject-rtos/docker-image/tree/072880b3#readme
I've been told it's too "bleeding edge" to be used in CI.
v0.17.3 also has libssl-dev which was the only thing we were missing.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Avoids the following redirection and warning:
warning: redirecting to https://github.com/thesofproject/sof/
Fixes: f59bb62e31 (".github: add shallow checkpatch to Github
Actions")
Also try to fix the display of one step name in the web UI.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Let's try to run checkpatch in an open-source and fast way while
leveraging Github's very good user interface.
Run checkpatch both with and without --strict; this has been a source of
confusion in the past, see
https://github.com/thesofproject/linux/pull/1988
Note this attempt does not rely on git merge-bases which has been found
to be not compatible with shallow cloning:
https://github.com/thesofproject/linux/issues/2556
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The singular "Action" makes it look like our workflow is an action. The
plural "Github Actions" is at least the name of the product; so it's
vague enough.
A technically acccurate name would be "Main workflow" but we have only
one so it would be useless plus we're next to "Jenkins" and others and
want to stay consistent with them.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Full translation except the IRC notifications, appreciate if someone
else can add later. Seems much faster.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>