Fixes: #25183
This commit fixes the issue where combining a 3rd party toolchain with
Zephyr SDK Tools would result in the Zephyr SDK overruling the toolchain
in use.
This is fixed by keeping track of current toolchain variant.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces backward compatibility with Zephyr SDK 0.11.1
and 0.11.2 so that users having one of those versions installed can
continue to use that version.
This remove the need to force users to update their SDK.
This is kept in independent commit to ensure it can easily be reverted
when minimum required Zephyr SDK is bumped to version 0.12.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces Zephyr SDK CMake config package.
This removes the need for setting ZEPHYR_SDK_INSTALL_DIR and
ZEPHYR_TOOLCHAIN_VARIANT when using Zephyr SDK in Linux.
It also allows to introduces never SDKs without breaking Zephyr.
For example, with this PR, the current Zephyr SDK is 0.11.1 but when
releasing 0.12 then the current Zephyr will no longer built.
This PR moves the Zephyr SDK CMake related code to the SDK and thus
allowing to use newer SDKs, as long as they are backwards compatible.
It also allows multiple SDK installations, and will automatically select
the version closet to the required version.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Print the name of the discovered toolchain as well as the variable
used to initialize it.
This is nice to know when doing remote support, since users will
sometimes misconfigure their toolchain and not know what that means.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It used to be that zephyr-sdk's were always contained all toolchains,
but as of recently it is also possible to download partial toolchains.
This patch fixes an issue where it was assumed that the zephyr sdk
contained an x86 toolchain. Now we glob for all known toolchains.
Note that the toolchain discovered by generic.cmake can be any generic
toolchain and does not need to be the same that is discovered by
target.cmake.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
For various reasons bump the min SDK required to 0.11.1. We need 0.11.x
for xtensa and ARM64 support.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Introduce HAS_NEWLIB_LIBC_NANO Kconfig option that the toolchain
specific Kconfig (gnuarmemb & zephyr 0.11) can select to convey that the
feature is supported.
This removes the need to if protect the NEWLIB_LIBC_NANO Kconfig with:
if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "gnuarmemb"
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Allow a given toolchain to specify Kconfig options that might be
relevant to a feature available in that toolchain.
For example, the ARM embedded GNU toolchain supports two variants of
newlib and you select the smaller one via a spec file. We can use a
Kconfig option like HAS_NEWLIB_LIBC_NANO to convey that this feature is
supported by that toolchain.
We look for the toolchain Kconfig in ${TOOLCHAIN_KCONFIG_DIR}/Kconfig,
and default TOOLCHAIN_KCONFIG_DIR to:
${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT})
toolchain specific cmake files can override the default if needed.
Additionally tweaked the zephyr/generic.cmake to use
${CMAKE_CURRENT_LIST_DIR} to reduce some duplication.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The XCC toolchain may come with Clang front-end depending on
how it's built. Currently, the only SoC/board using XCC is
the intel_s1000_crb and its XCC toolchain comes with Clang
3.9.0 which has a lot better support for C99 and C++11 than
the portion based on GCC 4.2 (which does not even support
C++11). So this change attempts to use the Clang portion
instead of GCC if the Clang executable exists.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Xtensa requires building a new toolchain for a specific SoC.
By default xtools built Xtensa toolchains all have prefix of
xtensa-zephyr-elf. In order to distinguish different toolchains,
they are now placed in their own directories under their SoC
name. This allows us to have multiple Xtensa toolchains
targeting multiple SoCs.
The additional level in path name is introduced in SDK v0.11
and sdk-ng master.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds the necessary bits to build the Xtensa HAL as
a module, and removes the bits to use the HAL built with
the Zephyr SDK.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds support for Zephyr SDK 0.11.* is based on the 0.10 support
with the following changes:
Handle how xtensa toolchains for given targets are organized in SDK
0.11.x. They have their own directories per specific xtensa SoC.
The x86_64 toolchain in the SDK has been updated to build for 32-bit
targets (as it has 32-bit soft float libraries). Use this toolchain for
all x86 builds.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Since x86_64-zephyr-elf is a multi-lib toolchain, m32/m64
need to be specified for the compiler to return the correct
library path when queried (e.g. --print-libgcc-file-name).
This affects the compile check done by CMake. Without these
flags, the compiler returns incorrect toolchain path (e.g.
requiring 64-bit libraries but returning 32-bit library path).
This also affects compiler flag checks for "-lstdc++". Incorrect
library path results in error when checking for "-lstdc++", and
this flag will not be used for the build. This results in
undefined references when compiling C++ code.
This creates target_x86.cmake to add the necessary flags for
CMake to use. The target_x86_64.cmake is also created to
mirror the same change.
Also removing the -m32 flags for host-gcc since we are not
building x86 targets with the host-gcc compiler.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The target.cmake for xtools needs to be updated for changes in
sdk-ng repo. This is simply a copy from the target.cmake for
0.10 SDK.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
There are two set of code supporting x86_64: x86_64 using x32 ABI,
and x86 long mode, and this consolidates both into one x86_64
architecture and SoC supporting truly 64-bit mode.
() Removes the x86_64:x32 architecture and SoC, and replaces
them with the existing x86 long mode arch and SoC.
() Replace qemu_x86_64 with qemu_x86_long as qemu_x86_64.
() Updates samples and tests to remove reference to
qemu_x86_long.
() Renames CONFIG_X86_LONGMODE to CONFIG_X86_64.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Encountered situation when sdk_version string was empty
(as the result of corrupted installation).
The version should had 0.0.0 format.
Patch add check for this and descriptive failure message.
Objective is to help the user to recognize the installation failure.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
We need SDK version 0.10.3 to fix a build regress on RISC-V when
linking. So bump the version to pickup that fix.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We want to use the riscv64 toolchain across the board for RISC-V. That
requires a min of the 0.10.2 SDK, so bump the version before we make
that change.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The SDK version is of the form X.Y.Z. Change the cmake scripts to be
based on X.Y of the version. This allows us to easily support newer
toolchains without having to explicitly add cmake files for the version
as well as removes duplication between those files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.
Redirects for the web documentation are also included.
Then zephyrbot complained about this:
"
New files added that are not covered in CODEOWNERS:
dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi
Please add one or more entries in the CODEOWNERS file to cover
those files
"
So I assigned them to those who created them. Feel free to readjust
as necessary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This forms the foundation for the abstraction of the binary tools,
where the following steps are taken:
- Move binary tool resolving, such as objcopy, objdump, readelf and
so forth, out of compiler definitions and place in a dedicated binary
tools folder with the binary tools supplier as subfolder, similar to
the compiler and linker directories.
- Create binary tool sets, gnu, host-gnu and llvm.
- Each toolchain selects the required set of binary tools by setting
BINTOOLS via its generic.cmake as it also does for compiler and linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This toolchain is no londer supported or needed. It was used to build
configurations that are now being removed.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This reverts commit b4078c557d / zephyrproject-rtos/zephyr#17495
This revert is needed for two reasons:
1. As reported by Lawrence King at
https://lists.zephyrproject.org/g/users/message/1566
this breaks incremental builds with ninja:
cd sample/hello_world
west build -b qemu_x86
touch src/main.c
west build -b qemu_x86
hello_world/build/../src/main.c:11: multiple definition of main';
app/libapp.a(main.c.obj):samples/hello_world/build/../src/main.c:11:
first defined here
collect2: error: ld returned 1 exit status
ar tf build/app/libapp.a
main.c.obj
main.c.obj
This does NOT break incremental builds with GNU Make, not sure why not.
2. Less urgently, I finally got someone from the CMake team to help me
and point me at an alternative solution that doesn't rely on CMake
internals: https://gitlab.kitware.com/cmake/cmake/issues/19474
I was about to try it when Lawrence reported the regression above.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Quoting GNU ar man/info page:
'D'
Operate in _deterministic_ mode. When adding files and the archive
index use zero for UIDs, GIDs, timestamps, and use consistent file
modes for all files. When this option is used, if 'ar' is used
with identical options and identical input files, multiple runs
will create identical output files regardless of the input files'
owners, groups, file modes, or modification times.
If 'binutils' was configured with
'--enable-deterministic-archives', then this mode is on by default.
It can be disabled with the 'U' modifier, below.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Check for ZEPHYR_SDK_INSTALL_DIR being invalid instead of
checking for SDK_VERSION being not defined. This change
relates to commit bb09c458c1 ("cmake: Prevent infinite
recursion").
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Ensure that xcc is at parity with gcc and clang by inferring missing
definitions based on those that it already provides.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This adds the necessary bits to utilize the x86_64 toolchain
built by sdk-ng for x86_64 when toolchain variant is either
zephyr or xtools. This allows decoupling the builds from
the host toolchain.
Newlib is also available with this toolchain so remove
the Kconfig restriction on CONFIG_NEWLIB_LIBC.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This new SDK:
() Fixes an issue with i586 toolchain where no coverage data
would be produced;
() Adds a new x86_64 toolchain for building x86_64
targets, decoupling x86_64 builds from host toolchain;
() Includes MIPS toolchain;
() Reverts bossa to older version to fix flashing issues;
() Turns on multilib support for RISC-V; and,
() Updates OpenOCD for TI and some ARC fixes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The logic is practically intact and is the following:
1. Use any host installed llvm/clang in the path in case
ZEPHYR_TOOLCHAIN_VARIANT=llvm is requested alone.
2. This can be further restricted with TOOLCHAIN_HOME.
3. And can be further overridden with CLANG_ROOT_DIR,
like previously.
So, only the unconditional restriction to /usr is lifted.
Together with fixing the unconditional set of TOOLCHAIN_HOME
by host tools for non-toolchain needs, this makes the logic
more flexible.
Now, after the logic is controllable by TOOLCHAIN_HOME, 3)
might be an extra, but is left intact for backward compatibility.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Use it's own variable HOST_TOOLS_HOME for host tools and don't
unconditionally set TOOLCHAIN_HOME, preventing the detection of
llvm/clang host toolchain.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
The LINKER variable is introduced to follow the same logic and flow as
the existing COMPILER variable: That is, each TOOLCHAIN is responsible
for choosing COMPILER and LINKER.
Currently, Zephyr's build system is hardcoded for GNU ld.
Reflect this in LINKER by letting all existing toolchains use GNU ld.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
If SDK_VERSION for whatever reason is unset cmake will end up in an
inifite recursion loop, which for me crashed using cmake version
3.13.4 and exits with an error using 3.14.1.
This may happen if ZEPHYR_TOOLCHAIN_VARIANT is set to "zephyr", but
ZEPHYR_SDK_INSTALL_DIR is invalid (or unset).
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add useful information to the error message printed when the installed
SDK does not fulfill version requirements.
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
Contrary to all other toolchains, the xcc toolchain had a hardocded
installation path. Replace this with XTENSA_TOOLCHAIN_PATH so users can
install in different locations.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When using xtools as toolchain, cmake searches the toolchain home
directory. However, if the first toolchain directory does not
begin with any character before "s", "sources" (if exists) would
become the first directory being probed. Since it does not
conform to "arch-vendor-abi" naming, cmake would fail.
So exclude "sources" from the list to avoid this issue.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
XCC is based on xcc, but is nothing like gcc and his many differences.
Instead of ifdeffing the gcc code with Xcc specifics, maintain it
standalone.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
We need to set SYSROOT_DIR as the last thing we do on target.cmake so
we reset how its set for xtensa. Otherwise when we build with newlib
we will not get the proper path to newlib headers in the toolchain.
This matches the behavior of 0.9.5/target.cmake
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
