XTOS is going to be deprecated on i.MX8ULP so prevent
building it by removing it from the list of supported
platforms from `xtensa-build-all.sh`. This is needed for
switching to Zephyr native drivers.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
To prepare for XTOS deprecation and switch to Zephyr native
drivers on imx8/imx8x, remove the ability to build SOF
with XTOS on them.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@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>
... 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>
Remove all support for cAVS 2.0 platformsm including Ice Lake and
Jasper Lake, they aren't supported any more.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Remove all support for cAVS 1.8 platformsm including Cannon Lake,
Comet Lake, Whiskey Lake and Coffee Lake, they aren't supported
any more.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Remove all support for cAVS 1.5 platformsm including Apollo Lake,
Sky Lake, Kaby Lake, Broxton and Gemini Lake, they aren't supported
any more.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Remove all support for Broadwell and Haswell platforms, they
aren't supported any more.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Remove all support for Baytrail and Cherrytrail platforms, they
aren't supported on the "main" branch any more. To build SOF for them
use the "table-v2.2" branch.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Environment variables like XTENSA_SYSTEM are an absolute CMake
pain. Add a link to the CMake FAQ and a one-line description why.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The rmb toolchain was added in commit 4e85dfc95f ("docker: add
AMD/Rembrandt gcc toolchain") and before.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
There was no actual "IPC3" value, it was ignored. The platform default
was used instead.
Stop ignoring invalid arguments, fail and report them.
Allow empty string as a no-op for scripting convenience.
Don't restrict IPC4 to tigerlake, it's not the job of
xtensa-build-all.sh to filter what's supported versus not.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Add ipc4 build support for tgl with IPC4_CONFIG_OVERLAY.
If IPC_VERSION is chosen as IPC4, then overlay configuration file
for different platforms will be used automatically without assigning
the configuration file with options.
Different configuration files will be used according to what platform
is building firmware for.
Signed-off-by: Xiaoyun Wu(Iris) <xiaoyun.wu@intel.com>
Recent combination of tgl and tgl-h building resulted in use of an invalid
defconfig file for tgl-h platform. This commit reverts that change.
Fixes: f1e6e1fdd3
Signed-off-by: Adrian Warecki <adrianx.warecki@intel.com>
Combined case label tgl and tgl-h similarly as in xtensa-build-zephyr.sh
Corrected code formatting.
Signed-off-by: Adrian Warecki <adrianx.warecki@intel.com>
If the user doesn't set the path to own private key, the default path is
placed in the variable containing the user's key. This causes a leak of the
default key of one platform to the others platforms, which will treat it as
a key supplied from the user.
Signed-off-by: Adrian Warecki <adrianx.warecki@intel.com>
The -a option was recently broken by the addition of platform(s) that
don't have a toolchain available in the Docker image. Every platform can
be built by someone but no one can built -a(ll) platforms right now.
Add a new platform array to make the distinction between default
platforms built by the -a option versus work in progress.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
No one else has it.
Gets rid of the only shellcheck warning.
Fixes commit 7453e3d571 ("scripts: add renoir support")
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>
... 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>
The configuration names with _2017 are a consequence of the way I did
the internal configuration update. To keep it simple I update these
build scripts.
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
XTOBJCOPY and XTOBJDUMP were added in June 2018 by
commit 27795ece0f ("scripts: fix xt-xcc build with wrong config") for
`./configure CC=$XCC OBJCOPY=$XTOBJCOPY OBJDUMP=$XTOBJDUMP ...` that was
used at the time.
The build system was switched to CMake in January 2019, notably with
commit 9840ecbbfe ("cmake: update xtensa-build-all.sh") and
commit 0fd97adfb0 ("cmake: add utility scripts") that defined
CMAKE_OBJCOPY and CMAKE_OBJDUMP)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
$ARCH was introduced in 2018 by commit b5af84deaa ("scripts: add smp
builds to xtensa-build-all.sh"). At the time used autotools and
`./configure --with-arch=$ARCH` were used.
In January 2019 the build system was migrated to CMake over several
commits, notably commit 9840ecbbfe ("cmake: update
xtensa-build-all.sh") that switched xtensa-build-all.sh to CMake and
removed its only use of ARCH. Also note commit 82b4da291b ("cmake:
defconfigs support") which added a few CONFIG_SMP defconfigs and
commit 905bad4252 ("scripts: xtensa-build-all: Add support to force
build UP Arch") using override.config.
Much more recently in June 2020: commit fd506970cc ("zephyr: kconfig:
rename CONFIG_SMP -> CONFIG_MULTICORE")
Zawinski's Law of Software Envelopment: adding lines of code is much
easier than removing the same amount and would be very impractical
without git. This one was easy enough.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As CMake forks one compiler process for each source file, the XTensa
compiler spends much more time idle waiting for the license server over
the network than actually using CPU or disk.
On my VM with 16 virtual cores, rebuilding one platform from scratch
with this commit goes down from 12s to less than 9s: more than 25%
faster. With Ninja it goes down from 11s to less than 8s. My license
server is 25ms away: a closer server does not need as many threads while
a more distant server would obviously benefit for even more
threads... while already getting an even better improvement than 25%
from just 3 times more threads! It's complicated and we probably don't
want to start the build by measuring latency to the license server.
The entire, purely local _gcc_ build is so fast (~ 1s) that observing any
the difference between -j nproc and -j nproc*N is practically impossible
so let's not waste RAM when building with gcc.
Also: log the $XTENSA_SYSTEM variable as it is required for incremental
builds; remove one apostrophe in the here-doc usage as it breaks the
parser of some editor (jed).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Notably:
- Log error and default MEU_OFFSET when meu -ver is not found.
- Explain rimage -s option
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
There is no such compiler as RF-2017.8 that is in use. The correct
compiler is RG-2017.8 for all i.MX platforms.
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
Add cmake -DINIT_CONFIG= option that can point at any initial file.
"make clean" does not delete .config any more.
Note reconfiguration does NOT causes recompilation because -imacros
hides the generated .h from CMake's dependency scan. This is not a
regression, that problems exists since -imacros was introduced. At least
it's now possible to "make clean" and rebuild without losing the .config
file.
Fix for #3617
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Lets use the same version of Xtensa toolchain as Intel in order
to avoid compilation problems.
It is difficult to support multiple toolchain versions because specific
headers needs to be updated, so lets have the same version supported
between IMX and Intel.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
The script already logs the full CMake command that is re-usable outside
this script... except for the PATH change. Expose that sneaky PATH
change.
Debugging every build issue starts with peeling the too many layers of
indirection.
Also fix some minor issue in the help message.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This makes it possible to switch to Ninja with a single line change
which can be useful to test build changes and issues.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Currently xtensa-build-all.sh has restriction to use rimage for tgl
signing, because rimage didn't support tgl. As rimage now has support
for tgl signing let's remove this limitation.
Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
Following commit 88b69cc2e5 ("scripts: xtensa-build-all: Add support
for building TGL and signing with MEU") we now have an unified and
flexible PRIVATE_KEY_OPTION that can do anything with very little code.
The -k option was never a good idea in the first place because it
already required an environment variable anyway (RIMAGE_PRIVATE_KEY)
instead of a command line argument so the code should have just checked
whether RIMAGE_PRIVATE_KEY was defined, that would have been
enough. Requiring the user to "double-confirm" with -k has been adding
extra complication for both the user interface and the implementation.
xtensa-build-all is effectively a "CMake configuration convenience"
script, however it shouldn't become an additional layer of indirection
and complexity and its interface should expose CMake (which is already a
layer of indirection!) as directly as possible.
See longer discussion in PR #3187
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
We switch to PCH-based names instead of CPU config names for tigerlake+
platforms, because we need to support multiple variants of PCHs based
on one CPU famile - for example TGL-H & TGL-LP.
Signed-off-by: Janusz Jankowski <janusz.jankowski@linux.intel.com>
Laurentiu Mihalcea