This is placeholder for base warning flags, common to most toolchains.
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>
The introduced macros are placeholders for the cmake parameter warning
level.
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>
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>
- Add examples for the latter.
- Point at each other and highlight how independent they are from each
other.
- State their inputs and outputs in plain English.
- Fix "git describe" error message giving the wrong impression that
everyone cares about BUILD_VERSION. Only the boot banner cares now.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Move PROPERTY_LINKER_SCRIPT_DEFINES to toolchain_ld_base.
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>
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>
On some systems where you don't have access to `PATH` and you can't
set the `ENV{PATH}` variable. You need to be able to pass the path
to the west executable down to the python script so it is better
for it to be set explicitly than assuming that it exsists as a
part of the PATH/executables in the shell being called.
Signed-off-by: Sigvart M. Hovland <sigvart.hovland@nordicsemi.no>
While configure_linker_script() may be useful for other linkers, it
currently only aimed at GNU ld. To really be useful among different
linkers, we would need to abstract its usage of the C preprocessor.
We can do this later, if needed.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
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>
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>
Move GNU ld linker specific flags related to orphan handling into
toolchain_ld_baremetal().
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>
Move --gc-sections flag to toolchain_ld_base()
Move --build-id=none flag to toolchain_ld_base()
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>
Modern versions of GDB support multiple architectures
with the same binary.
In fact, Ubuntu stopped shipping a gdb-arm-none-eabi
package, gdb-multiarch should be used instead.
This fixes a failure on those systems where otherwise CMAKE_GDB will be
assigned to CMAKE_GDB-NOTFOUND.
Signed-off-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
When importing a pre compiled imported library it is currently
required to perform three steps.
This commit introduces a helper function which allows the
user to import a library with a single function call.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
The intent of toolchain_ld_baremetal() is to collect the flags belonging
to non-hosted (i.e. POSIX-based) targets.
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>
* LINKERFLAGPREFIX's value is GNU ld specific, and
* LINKERFLAGPREFIX is not a convention always honored by all linkers.
Thus we shall not set it from the common root CMakeList.txt.
So we move to linker/ld/target.cmake.
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>
clang doesn't understand fortify at all, provide no op macro,
in order to handle the request to fortify in a generic way.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
In case TOOLCHAIN_HOME isn't explicitly reuqested,
(or indirectly forced with CLANG_ROOT_DIR), detect
any host installed clang in the path.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@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>
Host-tools don't unconditionally set TOOLCHAIN_HOME anymore,
but in case Zephyr's SDK toolchain is used, set TOOLCHAIN_HOME.
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>
Allow host installed clang to be used for native_posix when
ZEPHYR_TOOLCHAIN_VARIANT=llvm.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
The function zephyr_append_cmake_library works with
libraries that does not have source files.
This change removes an incorrect statement related
to that.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
toolchain_ld_base() represents flags that are fundamental to linking or
otherwise does not belong in any further specified linker flag category.
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>
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>
toolchain_cc_nostdinc does not only obtain flags (to be placed in a
variable), it obtains and applies them.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
In order to make board listing reusable by external tools, split it out
from the usage helper script into a new boards.cmake that can also be
called directly with cmake -P.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In windows an additional / is added when using zephyr-env.cmd
this causes a build error in some scenarios. It also creates
ugly file paths.
Signed-off-by: Sigvart Hovland <sigvart.hovland@nordicsemi.no>
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>
Just like board's can be placed in out-of-tree BOARD_ROOT's, we now
support DeviceTree sources and bindings being placed in out-of-tree
DTS_ROOT's.
This required for out-of-tree drivers that use DeviceTree.
To implement this we get rid of various user-settable CMake variables
like DTS_APP_BINDINGS, DTS_APP_INCLUDE, and instead have ZEPHYR_BASE,
APPLICATION_SOURCE_DIR and out-of-tree directories conform to using
the same DTS_ROOT concept and directory structure.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
All DT include directories are system directories, except for
dts/common. There is no reason for dts/common to diverge, so we align
it with the other directories to be consistent.
Also, we move it closer to the other include directories.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
After the rework in #12403, specifying a shield which has overlay
out of the tree causes unnecessary inclusions of overlays.
For every board root, overlays that have same index as
expected overlay are being included.
Fix this by removing already included overlays from SHIELD list.
Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
This is needed to remove noise when comparing binaries across git
commits and more generally for anyone who wants to manual
control/override the version number when building with or without a
.git/ subdirectory.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
While this race seems unlikely and harmless let's play it safe and
implement the usual solution: temporary file + atomic rename.
The race is unlikely and maybe even harmless because:
- Only sanitycheck seems to invoke cmake concurrently.
- Users rarely delete their ~/.cache/zephyr/ToolchainCapabilityDatabase/
- All concurrent cmake processes write the same, single byte to the same
files.
- Creating a single byte is at least very fast, so extremely short
window for others to read an empty file.
For additional background see links in issue #9992
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
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>
PR #14776 / commit 915a353255 changed function
zephyr_library_compile_options() to use MD5 instead of RANDOM for build
reproduction reasons. As later predicted by Sebastian Bøe in the PR
(thx), the names generated for these pseudo-libraries won't be unique
anymore if the exact same flag gets added more than once.
To reproduce the issue, simply add the following two lines in some
CMakeLists.txt file like samples/hello_world/CMakeLists.txt:
zephyr_library_compile_options("-Dfubar=barfu")
zephyr_library_compile_options("-Dfubar=barfu")
cmake will then fail like this:
CMake Error at zephyr/cmake/extensions.cmake:403 (add_library):
add_library cannot create target
"options_interface_lib_e689fdb7eb15d801c2f95dd61301fc5e" because
another target with the same name already exists. The existing
target is an interface library created in source directory
"zephyr/samples/hello_world". See documentation for
policy CMP0002 for more details.
Call Stack (most recent call first):
CMakeLists.txt:9 (zephyr_library_compile_options)
As requested by Sebastian, silently discard duplicate options just like
CMake does.
Fixes#15093
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Kconfig.modules used to be an empty file when no modules. PR #14667 /
commit bd7569f272 "cmake: Extracted Zephyr module processing into
python script" unintentionally changed that to no Kconfig.modules file
at all when no west and no modules. kconfig.py doesn't like that and
crashes. Restore the empty file.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fixes: #14513
This commit move the functionality of extracting zephyr modules into
generated CMake and Kconfig include files from CMake into python.
This allows other tools, especially CI to re-use the zephyr module
functionality.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
1. To support being called multiple times, the function
zephyr_library_compile_options() uses unique
options_interface_lib_${random} names. These only need to be unique, not
random. So replace them with a simple MD5 hash of the ${item} argument.
To reproduce quickly run:
sanitycheck -b -p qemu_xtensa --tag shell
... a few times and compare the output directories.
This bug sits for now at the top of the list of build reproducibility
issues the most bizarre and difficult to root cause. When running
sanitycheck over a large sample of configurations it was affecting
only qemu_xtensa/**/zephyr/arch/arch/xtensa/core/startup/Makefile
files (and their corresponding CMakeFiles/TargetDirectories.txt),
randomly ordering the following three Make targets and only these
three: rebuild_cache, edit_cache, arch__xtensa__core__startup.
The key to root causing was cmake --trace-expand which prints the random
string.
2. generate_unique_target_name_from_filename() also generated a random
string for the same uniqueness reason. This one was easier to root cause
and reproduce with: sanitycheck --tag gen_inc_file
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Currently, the Kconfig.modules file is placed in the build directory
relative to the CMake "project". But technically, the file is not
project-specific, but global, or build-directory specific.
So we move it up one level to the CMAKE_BINARY_DIR instead. Currently,
there is only one project, so this change has no effect, but this
enables us to have multiple projects in the future, which again
enables multi-image builds.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Set the revision to the v0.5.6 tag in west.yml and update the minimum
version. Barring any (more) major undiscovered issues, this will be the
version used with Zephyr v1.14.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Prepend -m32 to existing flags as opposed to silently override and
discard them:
- set(CMAKE_<tool>_FLAGS -m32 )
+ string(PREPEND CMAKE_<tool>_FLAGS " -m32")
This stops discarding additional flags passed with either cmake
-DCMAKE_<tool>_FLAGS="-fu -bar" or cmake -C params.cmake.
Note this bug was affecting only the combination of x86 and
CMAKE_<tool>_FLAGS. x86_64 wasn't affected and other, non-empty
CMAKE_<tool>_FLAGS_[DEBUG/RELEASE/etc.] weren't affected either.
Also convert flags string to list when invoking --print-libgcc-file-name
to support more than one CMAKE_C_FLAGS.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
No need to do this in arch code, all qemu variants speak the same
command line and the kconfig values we need are easily available.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Out-of-tree Kconfig frontends need to know which environment variables
are exported by Zephyr to Kconfig.
To support this we allow additional Kconfig python frontend targets to
be specified from out-of-tree.
This support was added on request by a third-party with a custom
Kconfig frontend.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When we build with newlib we don't set -nostdinc. In that case make
sure that we leave it to the toolchain to set the system include paths.
The one exception to leaving to the toolchain to set the system include
paths is the path to the newlib headers. Since we build
with -ffreestanding we need to make sure the newlib header path is the
before the toolchain headers. Otherwise the toolchain's 'freestanding'
headers get picked up and that causes issues (for example getting PRI*64
defined properly from inttypes.h due to __STDC_HOSTED__ being '0').
For newlib we accomplish this by having the only system header specified
by zephyr_system_include_directories() being just the newlib headers.
Note: for minlibc we leave things alone as things just happen to work as
the -I include of the libc headers takes precedence over -isystem so we
get the libc headers over the toolchain ones. For the newlib case it
appears that setting both -I and -isystem for the same dir causes the
-I to be ignored.
Fixes#14310
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
If one invokes cmake with west in the PATH but not inside a west
installation (i.e. in a monorepo setup), west will try to list the
zephyr modules issuing an error message.
Test if west list succeeds before using result for module testing.
Fixes#14177
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Parse the west version output and make sure both bootstrapper and
installation wests are up to date. This will still work after the two
are combined into what gets installed via PyPI.
Fixes: #13209
Signed-off-by: Marti Bolivar <marti@foundries.io>
Users often get confused when they change Kconfig sources and then
rebuild only to discover that nothing happens. To fix this we add a
dependency between re-running cmake, and all Kconfig sources, similair
to how touching CMakeLists.txt files cause CMake to re-run.
This fixes#5634
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
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>
In-tree, all usage of 'set_conf_file' is implementing the same
pattern (with some inconsequential differences).
To reduce copy-paste and get closer to dropping support for
'set_conf_file', we include this pattern into the built-in set of
patterns.
'set_conf_file' is causing issues for future extensions,
e.g. multi-image support, and is also the source of a lot of
duplicated code.
Note support for 'set_conf_file' is not dropped, it is only marked as
deprecated.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
MISRA rules (see #9892) forbid alloca() and family, even though those
features can be valuable performance and memory size optimizations
useful to Zephyr.
Introduce a MISRA_SANE kconfig, which when true enables a gcc error
condition whenever a variable length array is used.
When enabled, the mempool code will use a theoretical-maximum array
size on the stack instead of one tailored to the current pool
configuration.
The rbtree code will do similarly, but because the theoretical maximum
is quite a bit larger (236 bytes on 32 bit platforms) the array is
placed into struct rbtree instead so it can live in static data (and
also so I don't have to go and retune all the test stack sizes!).
Current code only uses at most two of these (one in the scheduler when
SCHED_SCALABLE is selected, and one for dynamic kernel objects when
USERSPACE and DYNAMIC_OBJECTS are set).
This tunable is false by default, but is selected in a single test (a
subcase of tests/kernel/common) for coverage. Note that the I2C and
SPI subsystems contain uncorrected VLAs, so a few platforms need to be
blacklisted with a filter.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Drop these CMake comments. It is redundant with a below comment to
describe 'app', and it is incorrect to state that omitting
boilerplate.cmake is permitted/supported.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
We had an if-statement around policy 79 because we used to need to
support CMake versions before 3.13.0. But now 3.13.1 is the minimum
required version so the if statement always evaluates to true and can
be omitted.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
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>
- newlib needs c standard includes (so no -nostdinc)
- xcc needs toolchain headers (so no -nostdinc)
- with host gcc:
- x86_64 should not build with standard includes (-nostdinc needed)
- native_posix should build with standard include (no -nostdinc)
..
..
To simplify, abstract this and move it to compilers/toolchains and still
depend on what the application wants.
Signed-off-by: Anas Nashif <anas.nashif@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>
Introduce toolchain_cc_asm macro to capture toolchain specific flags
related to assembly.
-D_ASMLANGUAGE is kept common for all, assuming -D as define flag is
supported by all compilers (which is almost the case).
No functional change expected.
Clang's flags are compatible with gcc, and are thus inherited.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.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>
We where defining the variable NOSTDINC_F after we tried to use it.
Move the definition before the first reference fixes things. When
-nostdinc now enabled we need to explicitly add the compiler include
path for x86_64 based builds (x86_64 and ARCH_POSIX).
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Introduce toolchain_cc_cpp_*-family of macros.
Move the following into the toolchain_cc_cpp_* macros:
* Common base set of flags
* C++ standard version
* RTTI
* Exceptions
These macros must be implemented by every compiler port.
These macros set the respective flags, but leaves logic and control to
the root CMakeLists.txt file.
No functional change expected.
Clang's C++ flags are compatible with gcc, and are thus
inherited.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
We have been overriding OVERLAY_CONFIG coming from tests. Concat all
files and create one variable that we pass to kconfig as list.
Fixes#13320
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introduce toolchain_cc_optimize_for_* family of macros.
Each macro represents a general optimization class.
Each macro is then responsible for setting an output variable to that
class-of-optimization's flag.
The names of these output variables are decided from the root
CMakeLists.txt.
No functional change expected.
Clang's optimization flags are compatible with gcc, and are thus
inherited.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Make kconfigfunctions.py agnostic to where GENERATED_DTS_BOARD_CONF is
located.
We don't want to encode the path of GENERATED_DTS_BOARD_CONF into more
places than necessary. Also, re-using GENERATED_DTS_BOARD_CONF makes
it easier to change where generated_dts_board.conf is located.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
We were select host compiler from the generic gcc compiler section which
is used for cross toolchains. This arch should use the host-gcc compiler
definition instead.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit allows for Zephyr modules to be natively integrated into
the build system with CMakeLists.txt and Kconfig files.
The sourcing of module files are done in following order:
- If <module>/zephyr/module.yml exists, use cmake and kconfig settings
for sourcing of additional file
- Else if <module>/zephyr/CMakeLists.txt exists, source this file into
CMake build tree and add <module>/zephyr/Kconfig as osource
If none of the above files are present, the project is considered to
not be a Zephyr module
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
This commit introduces a Kconfig option for ARM SoCs, to signify
that the SoC implements a double-precision floating point unit.
The option is utilized in cmake/fpu-for-gcc-m-cpu to select the
appropriate GCC compile option flag for FPU.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
newlib is not supported with this toolchain, so mark it as such and
filter tests based on the variable defined in the toolchain file.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introduces the ARCH_ROOT argument, similar to BOARD_ROOT and SOC_ROOT.
This enables support for out-of-tree architectures.
The ARCH_ROOT out-of-tree layout is expected to be the following:
* ${ARCH_ROOT}/arch/${ARCH}/
* ${ARCH_ROOT}/include/arch/${ARCH}/ (Optional)
Signed-off-by: Klaus Petersen <kape@oticon.com>
Expose ZEPHYR_TOOLCHAIN_VARIANT so that Kconfig can make choices based
on how its set. For example we RISCV_GENERIC_TOOLCHAIN if the variant
is 'zephyr'.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Based on work from Sebastian Bøe and updated to current tree.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Expose PROJECT_BINARY_DIR to kconfig since we will we looking for
generated files from dts pass in the future and need to know the
location of those files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We had been search for <BOARD>.yaml, however its possible that doesn't
match anything and we actually use <BOARD>_defconfig in
boilerplate.cmake. So search for *_defconfig instead of *.yaml to
generate the <BOARD> list.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
PR #9522 series ending with commit c2c9265b7d ("tests: cmsis: Disable
two cmsis portability tests on x86_64") added -mx32 support for the
x86_64 ARCH and qemu_x86_64. While this was implemented in
"compiler/gcc/target.cmake" as fall back from cross-compilation to the
host compiler, it worked with a direct ZEPHYR_TOOLCHAIN_VARIANT=host
too.
Later, -lgcc was added to "compiler/host-gcc/target.cmake" by PR #12674
to fix the -m32 x86 build. This broke the x86_64 build when using
ZEPHYR_TOOLCHAIN_VARIANT=host because even "multilib" packages usually
don't feature the -mx32 version of libgcc.
Fix this by excluding -lgcc in compiler/host-gcc/target.cmake just like
compiler/gcc/target.cmake always did for x86_64.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Introduce the first of the toolchain_cc-family of macros:
toolchain_cc_security_fortify and toolchain_cc_security_canaries.
No functional change expected.
Fortify source is not supported by Clang, but this commit retains
current behavior.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting easier porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Since we install west from pip and it becomes an executable, use it
directly assuming it's in the user's PATH.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Add missing -lgcc when compiling with ZEPHYR_TOOLCHAIN_VARIANT=host
merely copying some existing code from
'compiler/{clang,gcc}/target.cmake'.
This fixes compilation for the following boards with an x86
microprocessor:
galileo, minnowboard, qemu_x86, qemu_x86_nommu, up_squared,
up_squared_sbl
Compilation of the following boards with an X86_IAMCU microcontroller
still fail with a "cannot find -lgcc" error:
arduino_101, qemu_x86_iamcu, quark_d2000_crb, quark_se_c1000_devboard,
tinytile
This is _not_ a regression because these boards _already_ failed with
"undefined reference to __udivdi3" and other libgcc symbols.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This fixes the following error on all x86 BOARDs (qemu_x86,
galileo,... see "make usage" for the complete list) when compiling
assembly files with ZEPHYR_TOOLCHAIN_VARIANT=host:
cc1: error: CPU you selected does not support x86-64 instruction set
This also fixes the following error when compiling minnowboard,
up_squared and up_squared_sbl boards with ZEPHYR_TOOLCHAIN_VARIANT=host:
cc1: error: -mpreferred-stack-boundary=2 is not between 3 and 12
This fix alone is not enough to compile any of these boards; however it
moves compilation much further to the next, unrelated failure(s),
namely: 'undefined __udivdi3' and other libgcc symbols for all x86
boards; + some other, additional issues for some boards. See next
commit.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
We'd get output from a cmake build that would have lines like:
Version: DTC 1.4.7
Version: DTC 1.4.7
This was a side effect of check_dtc_flag. Add the OUTPUT_QUIET option
to execute_process to supress this output.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
A GCC-based toolchain may require additional, toolchain-specific
values in CMAKE_REQUIRED_FLAGS to perform compiler checks properly,
but gcc.cmake clobbers any values the user provides.
Preserve them instead, allowing users to give their own compiler
checking flags at generation time.
The details for the particular issue that inspired this are described
in https://github.com/pulp-platform/pulpino/issues/240.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Ensure that changes to DeviceTree sources cause CMake to be re-run
when make/ninja is invoked.
Note that this is not perfect, as it does not cover files that are
\#included, but it will cover most DT changes.
This fixes#12692
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
extract_dts_includes.py has been generating DT output and then
concatenating it with fixup header files to create
'generated_dts_board.h'.
In this patch we instead introduce a source file named
'generated_dts_board.h' and have it \#include the appropriate DT
output and fixup files.
This results in a simpler system because users can now read
'generated_dts_board.h' as C source code to see how fixup files and
generated DT output relate to each other. Whereas before they would
have to either read documentation or python code to gain the same
understanding.
Also, it reduces the scope and complexity of one of our most bloated
python scripts, extract_dts_includes.py.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
dtc 1.4.6 doesn't support the -Wno-unique_unit_address flag. We need to
check that the flag is supported before using it on pre dtc-1.4.7
versions.
Fixes#12685
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Depending on the installed and enabled SDK, we now load the right
configuration allowing people to migrate gracefully to the new SDK.
The selection is done based on the version of the SDK. Minimal required
SDK is still kept as 0.9.5.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
In Zephyr we have dts in which multiple peripherals can be at the same
MMIO address. So we want to disable the `unique_unit_address` check via
(-Wno-unique_unit_address). However, newer dtc support a check that
makes sure if we have duplicate unit-address devices that only one is
enabled. So if the dtc flag is supported we enable
(-Wunique_unit_address_if_enabled).
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add a function that let's us check if a given dtc flag can be used with
the version of dtc we have. This lets us utilize specific warning flags
that might not exist in older dtc versions and still have things work
properly.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
There is an effort underway to make most of the Zephyr build script's
reentrant. Meaning, the build scripts can be executed multiple times
during the same CMake invocation.
Reentrancy enables several use-cases, the motivating one is the
ability to build several Zephyr executables, or images, for instance a
bootloader and an application.
For build scripts to be reentrant they cannot be directly referencing
global variables, like target names, but must instead reference
variables, which can vary from entry to entry.
Therefore, in this patch, we replace global targets with variables.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Rather than specifying SHIELD via Kconfig, we move it to being
specified via the command line, similar to board.
So we can do:
-DSHIELD=x_nucleo_iks01a1
or, for multiple shields:
-DSHIELD="x_nucleo_iks01a1 frdm_kw41z"
Following cmake change, update x_nucleo_iks01a1 sample in order
not to enable CONFIG option anymore but set SHIELD cmake option.
Last, update documentation to reflect this change.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
By default Renode is searched for in the system PATH.
The PID is stored in renode.pid - the application must be killed with a
signal after a test.
With the XWT gui layer disabled all UART output is directed to the
stdout.
Signed-off-by: Dawid Wojciechowski <dwojciechowski@internships.antmicro.com>
Signed-off-by: Jan Kowalewski <jkowalewski@antmicro.com>
Signed-off-by: Piotr Zierhoffer <pzierhoffer@antmicro.com>
This patch adds a x86_64 architecture and qemu_x86_64 board to Zephyr.
Only the basic architecture support needed to run 64 bit code is
added; no drivers are added, though a low-level console exists and is
wired to printk().
The support is built on top of a "X86 underkernel" layer, which can be
built in isolation as a unit test on a Linux host.
Limitations:
+ Right now the SDK lacks an x86_64 toolchain. The build will fall
back to a host toolchain if it finds no cross compiler defined,
which is tested to work on gcc 8.2.1 right now.
+ No x87/SSE/AVX usage is allowed. This is a stronger limitation than
other architectures where the instructions work from one thread even
if the context switch code doesn't support it. We are passing
-no-sse to prevent gcc from automatically generating SSE
instructions for non-floating-point purposes, which has the side
effect of changing the ABI. Future work to handle the FPU registers
will need to be combined with an "application" ABI distinct from the
kernel one (or just to require USERSPACE).
+ Paging is enabled (it has to be in long mode), but is a 1:1 mapping
of all memory. No MMU/USERSPACE support yet.
+ We are building with -mno-red-zone for stack size reasons, but this
is a valuable optimization. Enabling it requires automatic stack
switching, which requires a TSS, which means it has to happen after
MMU support.
+ The OS runs in 64 bit mode, but for compatibility reasons is
compiled to the 32 bit "X32" ABI. So while the full 64 bit
registers and instruction set are available, C pointers are 32 bits
long and Zephyr is constrained to run in the bottom 4G of memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Host toolchains don't tend to provide an x32 libgcc. But we don't
actually need one for existing code. This is fragile, but better to
work for all but obscure cases than break outright.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Networking apps may require these rules (as echo apps) even on
non-Ethernet based configuration.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Xtensa toolchain has a HAL library that needs to be compiled in similar
to how we do this with the Zephyr SDK.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move to latest cmake version with many bug fixes and enhancements.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Follow the same convention as that of ccache.
Improve readability of boilerplate.cmake file.
Move inclusion of version.cmake up to satisfy git.cmake dependency.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Fixed a bug where an old version of python on path would break the
python detection mechanism.
This fixes#12066
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Cosmetics, no functional change expected.
Fixed leading space alignment.
Replaced tabs with spaces.
Emulation error message output is now aligned.
To locate tabs in cmake, the following bash is useful:
grep -PRil "\t" * | grep -i cmake | grep -v ^sanity
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Aid user in understanding what CMake expects of:
* Document and add CMAKE_SYSTEM_VERSION
* Document CMAKE_SYSTEM_NAME
* Document CMAKE_SYSTEM_PROCESSOR
* Document BUILD_SHARED_LIBS
* Document Policies CMP0002, CMP0079
CMAKE_SYSTEM_VERSION is required officially by CMake, but appears
unused -- at least now we are compliant.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
CheckCCompilerFlag and CheckCXXCompilerFlag does not belong to
extensions.cmake since they are standard CMake files. Boilerplate
seems more appropriate.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
These variables affect how CMake locates programs, libraries, include
files, and CMake packages. But the defaults are sufficient for Zephyr.
NEVER: Only host system's root will be searched.
ONLY: Only the paths specified by a variable will be searched. Typically
these paths point to cross-compilers.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Split up the toolchain configuration into two phases, generic and
target. The 'generic' phase configures the toolchain just enough to be
able to preprocess DT files. The 'target' phase completes the
configuration with target-specific configuration.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When building with clang symbols from the runtime library, like
__divdi3 were not being resolved. To fix this we add the "library path
for the currently used compiler runtime library" to the link path.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Align 'clang' with 'gcc' by having it also use 'find_program' instead
of 'set' to assign toolchain paths.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Align 'clang' with gcc by having it also set CMAKE_C_COMPILER in the
'compiler' build script instead of the 'toolchain' build script.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The 'llvm' and 'clang' build scripts have been named strangely. It is
more natural for 'clang' to be the compiler, and 'llvm' to be the
toolchain.
This commit rectifies this by renaming the files.
This also fixes#11187
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
CMake parses the Kconfig output for 'CONFIG_*' symbols and adds them
to the CMake namespace.
It does the same for DT, but has only been including 'CONFIG_' symbols
and been ignoring the 'DT_' symbols.
For DeviceTree to be useful, it's information needs to be accessible
from CMake, just like Kconfig is.
To this end we also introduce the 'DT_' symbols into the CMake
namespace.
This resolves#11109
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Generalize 'import_kconfig' to support parsing symbols with other
prefixes than 'CONFIG_'. This will eventually allow us to also import
'DT_' symbols into the CMake namespace.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Due to popular demand there exists an experimental feature with
undefined and undocumented semantics that permits Kconfig option to be
specified on the CMake CLI.
Like so:
cmake -DCONFIG_BUILD_OUTPUT_BIN=y
This patch fixes a bug where it was possible to have a mismatch
between the build/zephyr/.config file and the CMake namespace of
'CONFIG_' values.
We now pop all CLI Kconfig symbols from the CMakeCache.txt and then
push only the CLI Kconfig symbols that exist in the active .config
file.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Fixed#11980, a bug where a build failure occured when 'python' was
not on path.
There was a bug in the implementation where it failed to detect that
'python' was not on path. This is now fixed.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Fixed whitespace such that 'XTOOLS_TOOLCHAIN_PATH' is vertically
aligned.
Also, combined two cmake invocations of 'list' into one.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
ARCH is available before CONFIG_ARCH, and is otherwise identical. So
it is better to use ARCH than CONFIG_ARCH as this allows the code to
be moved around more freely.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Drop the seemingly unused XCC_BUILD variable because it depends on
Kconfig and we need to cut the toolchain's dependency on Kconfig.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Users expect that not just "some" compatible python is detected, but
also that it will be the 'python' executable from PATH, at least when
this executable is valid.
To this end rewrite FindPythonInterp to give this executable the
highest priority.
This fixes#11857
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
In CMake 3.13 a warning is produced if one does not explicitly state
what the policy for CMP0079 should be. To resolve this warning we set
policy CMP0079 to OLD.
This is expected to have no semantical change. When we want a
semantical change we can flip the policy and port the build scripts to
the new behaviour.
This fixes#11794
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This patch creates a rule in the cmake to trigger the generation
of linker_relocate.ld and code_relocation.c files.
The linker_relocate.ld will create appropriate sections and will
link the required functions or variables from all the selected
files.
The code_relocation.c will have code that is needed for
initializing data sections and copy of text sections(if XIP).
Also this will contain code that is needed for zeroing of bss.
The procedure to invoke this feature is:
1. Enable CONFIG_CODE_RELOCATION in the prj.conf
2. Inside CMakeList.txt in the project we need to mention
all the files that needs to get relocated.
zephyr_kernel_code_relocate(src/*.c SRAM2)
Where the first argument is the file/files and the second
argument is the memory where it has be placed.
NOTE: The file argument supports glob expressions.
NOTE: Step 2 can be done as many times as required. And relative
paths can be given here.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Move libapp.a into it's own directory. This would make it's placement
consistent with how zephyr.elf is placed.
E.g. it might now look like:
ls b/*
b/build.ninja b/CMakeCache.txt b/cmake_install.cmake b/rules.ninja
b/app:
libapp.a
b/CMakeFiles:
3.12.0 cmake.check_cache CMakeOutput.log TargetDirectories.txt
app.dir CMakeError.log CMakeTmp
b/zephyr:
arch kernel subsys
boards lib tests
cmake liboffsets.a zephyr.bin
CMakeFiles libzephyr.a zephyr.elf
cmake_install.cmake linker.cmd zephyr.hex
ext linker_pass_final.cmd zephyr.map
include linker_pass_final.cmd.dep zephyr_prebuilt.elf
isrList.bin misc zephyr.stat
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This patch adds a dependency from the 'flash' target to
the 'mergehex' target IF files to be merged are configured.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Some toolchains are built with multilib enabled in order to provide
multiple versions of the same library, optimized for different ABI
or architecture. They require the the ABI/architecture/CPU selection
options to be passed at linked time. This is important for example
when linking with newlib.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Allow user to add externally built hex files to the cmake property
HEX_FILES_TO_MERGE. The hex files in this list will be merged
with the hex file generated when building the zephyr application.
This allows users to leverage the application configuration
available in Kconfig and CMake to help decide what hex file
should be merged with the zephyr application.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Add script and cmake functions for automatically generating Character
Frame Buffer (CFB) font header files from image files, TrueType, or
OpenType font files.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Align how DT and Kconfig print log output to be more consistent.
For instance, Kconfig does not state which header file it generates,
so we remove this from DT.
Also, Kconfig states which sources it uses, which is useful to know
when there is a build failure, so we align with Kconfig by printing
the DT source and overlay files.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The 'FindPythonInterp' that is distributed with CMake 3.8 is affected
by bug: https://github.com/zephyrproject-rtos/zephyr/issues/11103
To work around this, until we upgrade to 3.13, we copy and patch the
3.8 version of 'FindPythonInterp' into the Zephyr repository.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Copy the 3.8.2 version of FindPythonInterp.cmake into the repo so that
we can patch it and fix#11103.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When we move DT infront of Kconfig we are going to need access to a C
toolchain before Kconfig is evaluated. This means it will not be
possible to specify the toolchain used through Kconfig.
To deal with this we ...
Drop support for specifying CROSS_COMPILE through Kconfig. Still
available is the ability to specify CROSS_COMPILE through the
environment or through a CMake variable.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
CMake prints a helpful error message with all the boards supported
when a board name has been misspelled. But CMake also
remembers (caches) the corrupted board name and refuses to change it
until the board directory has been cleared.
CMake is rightly hesitant to change the board, as other cached
variables depend on what the board is. But it is safe to change the
board just after it has been selected, because we verify it's
correctness before using it to calculate other variables.
So to support the use-case of changing a misspelled board
name (without clearing the build directory) we unset the cached board
when it is invalid.
Also; change the now unused (in-tree) macro 'assert_with_usage' to
'print_usage'.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
In addition to zephyr/include and zephyr/dts also scan
the dts directory within the application source directory
for files included by the DTS.
Allows to have application specific DTS includes. This
is especially useful for out of tree drivers.
Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
Danny Oerndrup