Quoting @andyross in
https://github.com/thesofproject/sof/pull/7668#issuecomment-1561587959
> OK, as it turns out when running native_posix+fuzzing, the fuzzer
> output goes to stderr (and appears here) where the console output goes
> to stdout, and is currently being discarded. For a sanitizer-detected
> failure, that's actually fine as the stack trace will show up in the
> CI logs. But this was just a call to posix_exit(), which is an "error"
> to the fuzzer but not very informative to us without knowing the
> software state that led to it. Most likely this is a Zephyr
> panic (e.g. an assertion failure -- not a trap like SIGSEGV/SIGILL
> that would be caught by the host OS and thus libfuzzer), because the
> default fatal error handler is to tell the arch layer to do a system
> halt, and native_posix implements this by exiting. And it's certainly
> not unlikely to have been triggered by the fuzzing.
> Basically: @marc-hb if we could arrange to save the stdout of the
> offending fuzz process on failure that would be great. Alas this
> particular incident may have been lost, but there will surely be more.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This has bitrotten vs. the newer code upstream at oss-fuzz, involves
an expensive docker container build, and provides little value vs. the
newer fuzz.sh script that runs in the regular CI containers.
Let oss-fuzz handle the deep validation. We should be using fuzzing
as a smoke test via the existing scripts.
Signed-off-by: Andy Ross <andyross@google.com>
This got merged too fast. Turns out it broke the newer fuzz
integration that was in the same YAML file. Also there are some
evolving review comments. Will resubmit.
This reverts commit 11e57f5030.
Signed-off-by: Andy Ross <andyross@google.com>
Fuzzing via the new framework is now integrated at oss-fuzz upstream,
so there's no point to keep this in SOF anymore. The github workflow
has bitrot vs. the newer build.sh, and that docker build is very
heavyweight vs. the newer fuzz.sh smoke test that runs in the regular
build container anyway.
Signed-off-by: Andy Ross <andyross@google.com>
Runner OS for the Zephyr workflow had been updated to Ubuntu 22.04,
so upgrading this workflow too.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
New Zephyr Docker container v.26.4 is based on Ubuntu 22.04,
upgrading build-linux job OS to match the one in the container.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Installation of new Zephyr SDK 0.16.1 does not require unzip anymore
in the setup.cmd script. This tool had been replaced by 7z that is
by default present on all Github Windows runners.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Zephyr main branch requires new Zephyr SDK.
Upgraded version of Zephyr SDK to newest available v0.16.1 in the
build-windows job. New SDK is backward compatible with old Zephyr
revisions so the upgrade is applied to all CI.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
This hasn't been required since Zephyr commit 91902c5fd4db ("cmake: add
sparse support to the new SCA infrastructure")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Let's try to fix the error below spotted in
https://github.com/thesofproject/sof/actions/runs/4981366388
I have no idea why this worked before and not anymore but if this makes
apt happy then we're happy.
```
libstdc++-12-dev:i386 :
Depends: libstdc++6:i386 (>= 12.1.0-2ubuntu1~22.04) but it is not
going to be installed
Depends: libc6-dev:i386 (>= 2.13-0ubuntu6) but it is not installable
```
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
We import hal_xtensa indirectly through zephyr/west.yml.
When overriding the Zephyr revision in sof/west.yml to test the Zephyr
main branch "zmain", we must also update the version of hal_xtensa
specified in zephyr/west.yml. Stop doing a manual, single repo git fetch
and use a submanifest to perform this correctly. This is exactly why
submanifests/ were added in the first place.
These fixes the imx8m compilation error spotted and discussed
in (unrelated) #7579 following the IMX rename in
https://github.com/zephyrproject-rtos/zephyr/pull/57084 and
https://github.com/zephyrproject-rtos/zephyr/pull/57795
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Search and replace checkout@v2 with checkout@v3.
This finally gets rid of all warnings "Node.js 12 actions are
deprecated".
We've been using v3 in a few other places and never met any backwards
compatibility issue.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This makes sure Zephyr's -fmacro-prefix-map is working and keeps the
builds reproducible when using a recent enough toolchain.
As found in the CONFIG_ASSERT PR
https://github.com/thesofproject/sof/pull/6530#issuecomment-1482330214
this is not true for old Xtensa toolchains.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Sparse output is spammed with "Variable length array" warnings from
Zephyr logging system. The use of VLAs there can be disabled via
Kconfig. Do that to avoid exceeding sparse's warning maximum and
losing important warnings.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Recent experience has shown that upstream Zephyr regressions are much
more common than platform-specific failures. So move the Zephyr version
in first position, so this will group zephyr regressions and make them
much more obvious.
Use very short keys for the revisions because the left column in
Github's results "checks" tab is very narrow and cannot be resized.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Real-world experience has proved again that big READMEs are not enough,
not even when they're only a couple lines away as the one added in
commit 8fd351ea9a ("west.yml: add warning to keep git submodules in
sync"). Only some failure / red color stand a chance.
It also seems some people rarely use "git status". This was discovered
in commit d9eb16aa66 ("cmake: add warning when git submodule changes
are found") but is still surprising.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fixes commit 98b4625a0d (".github/daily-tests.yml: add
sparse-zephyr.yml") and daily tests which just started failing as
found by @aborisovich in
https://github.com/thesofproject/sof/actions/runs/4333619550 and
others (thanks!).
Signed-off-by: Marc Herbert <marc.herbert@gmail.com>
Explain when this file applies and why there is a .c/.h difference.
I still don't understand why .c file don't use /* SPDX */ but I think
it's still worth quoting a tiny bit from the official documentation
anyway.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fetching different tags causes `git describe` output to be different.
Fixes commit 68b49c186e (".github/zephyr: switch Windows build to west
update --narrow")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Other jobs typically use `west update --narrow` which is faster but also
able to fetch "wild" SHA1s from any random place! It is useful for
testing unmerged Zephyr commits but risks accepting "invalid" zephyr
commits; this will not.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Caching `docker pull` does not work for size and other reasons, add a
link to the failed experiment.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Pleasing checkpatch is hard when adding new files.
This is tricky and comes up every time someone adds new files, examples
in #6284, #6796, #6931 , etc.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This saves a lot of scrolling in the next, most popular build step.
Missed in previous commit 52223eba2d (".github/zephyr: docker pull in
a separate step")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
From
https://github.com/actions/upload-artifact#uploading-to-the-same-artifact
> Warning: Be careful when uploading to the same artifact via multiple
> jobs as artifacts may become corrupted.
Fix bug where IPC3 and IPC4 builds were randomly overwriting each
other and the same bug with different Zephyr revisions.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Github allows to store build artifacts for 90 days after the build.
Somebody might want to examine the output of the build, now can
easily download everything that job produces.
In example, compile_commands.json file contains all compilation
commands in verbose that are not visible in the build log
by default.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Recently new feature had been introduced to Github actions
"concurrency" that allows to define a name for a group of workflows
that will cause old workflow to stop if the new one had been created
and the group name matches.
This improves usage of resources in SOF project by cancelling
running workflows when pushes to pull requests are done frequently
before old jobs are completed.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Zephyr workflow had been added new build-windows job.
It makes sense to rename old "build" job yo "build-linux"
for consistency.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
This upgrade was already performed for other jobs in commit
f71eb15818 (".github/workflows: upgrade actions/checkout@v2 -> v3")
and everything went fine. Finish the job and get rid of the last
warnings in the daily tests (example:
https://github.com/thesofproject/sof/actions/runs/3709176785)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Partial revert of commit 687c6f305e (".github: workflow: removed
legacy RTOS platforms from Zephyr build") that was a bit too
"enthousiastic".
When someone breaks the Zephyr+IPC3 build we'd like to: 1. notice, 2.
tell whether it's Intel-specific, IMX-specific or not specific.
This is a one-line change and unlike testing, building is "free".
It can be removed in a second when/if that becomes a burden.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The list is getting too long and the "checks" box in the Github User
Interface is small.
Fixes commit 543acc124d (".github/workflows: add tgl-h IPC4 build")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
--pristine makes no difference for github but it's a good for anyone
trying to reproduce results and copying the command.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This should get rid of most warnings in daily tests
```
Node.js 12 actions are deprecated. For more information see:
https://github.blog/changelog/
2022-09-22-github-actions-all-actions-will-begin-running-on-node16...
Please update the following actions to use Node.js 16: actions/checkout@v2
```
Example at
https://github.com/thesofproject/sof/actions/runs/3597808171
v3 seems backward compatible. Upgrade only the most used instances for
now (most used because of the `matrix` of platforms), upgrade everything
in a few days if no issue is spotted.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Legacy platforms not meant to work with Zephyr were added
in commit ".github: compile-test multiple zephyr revisions + IPC4"
(8543f5c889).
Removed them from CI as they never should be built in the first place.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Existing daily tests run "Main Action" workflow from
pull-request.yml at 00:00 UTC time.
Tests may also be executed manually from Github Action tab.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Reusable actions may be triggered by other actions in the
repository. Those two actions will be triggered by new
daily testy action at specified time of the day.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Zero code change, pure move to a new file.
Similarity is not a very strong reason for the sparse job to be in the same
file as regular Zephyr compilation.
Unlike plain Zephyr compilation, the sparse job is very much a "work in
progress" which is currently failing all the time. Moving it to a
different file/workflow provides more configuration flexibility.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Add the wrong compiler currently expected by the Zephyr build system,
very easy one-line change later, get sparse results for MTL NOW!
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Make prints a line for every topology that is already up to date and not
rebuilt. It's impossible to see what was done.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
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>
Marc Herbert