The CMake documentation for 'project' states "Call the project()
command near the top of the top-level CMakeLists.txt". Meaning, it
should be run as early as possible.
An obscure internal error was observed when 'project' was located in
zephyr/CMakeLists.txt and was observed to be fixed after moving
'project' earlier, hence this patch that moves it earlier.
Invoking project depends on knowing information about the toolchain so
it is placed after target_toolchain.cmake.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Should be --bindings-dirs, not --bindings-dir, but the 'argparse' module
supports shortening flags, so it worked anyway.
Broke my grepping though.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This PR adds the possibility to specify ZEPHYR_EXTRA_MODULES from an
environmental variable. To add a custom module mymodule in
path/mymodule the variable ZEPHYR_EXTRA_MODULES can be set in
`.zephyrrc` as `export ZEPHYR_EXTRA_MODULES=path/mymodule`.
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
We are observing warnings when test-compiling toolchain flags that
look like:
cannot find entry symbol _start; defaulting to 00000000000010d4
To fix this warning we explicitly set an entry point to an arbitrary
address. The files are only compiled, not run, so the entry point does
not need to be correct.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Mimic what we have in cmake/compiler/gcc/target.cmake for clang
targetting ARM. Match gcc behavior by setting -fshort-enums
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
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>
Some confluence of recent changes resulted in builds with
application-specific bindings being unable to find bindings present in
the system directory. Add quotes and splits as necessary to propagate
multiple directories through the system.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Add qemu_x86_long board (with CONFIG_X86_LONGMODE=y) for testing.
This requires adding support to soc/ia32 for long mode (trivial),
and adding a quick 64- to 32-bit ELF conversion before invoking
QEMU, which apparently doesn't like 64-bit kernel files.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
* Add support to search for a board specific shield in
<SHIELD DIR>/boards/<SHIELD>/<BOARD>.{overlay,conf}. So we can
support something like:
x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.overlay
x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.conf
Fixes#19078
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
* Fix dir name when shield name doesn't match the dir name. So for
shield 'x_nucleo_iks01a3_shub' we will look in now for
x_nucleo_iks01a3/boards/<BOARD>.{overlay,conf} instead of
x_nucleo_iks01a3_shub/boards/<BOARD>.{overlay,conf}
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Move handling for shield boards/board.overlay, shield.conf and
boards/board.conf inside the SHIELD_LIST check.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
It turns out that 'check_compiler_flag' has not been working for flags
that start with -Wno-. This has caused old compilers to accidentally
use flags that they do not support.
To fix this we check for compatibility with the appropriate -W flag
instead and infer the -Wno- compatibility from this check.
The root cause of this problem is explained well here:
https://github.com/zephyrproject-rtos/zephyr/pull/18922#discussion_r321537098
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Error-out when 'project' is invoked before boilerplate.cmake is
included. This is not supported and causes obscure errors.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Drop the old deprecation warning about
ZEPHYR_TOOLCHAIN_CAPABILITY_CACHE. Sufficient time has passed to allow
users to migrate.
Signed-off-by: Sebastian Bøe <sebastian.boe@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>
Now when SMP support for ARC is available we may introduce a simulation
platform which might be used for testing & development for SMP setups.
One important note is stand-alone nSIM (as well as its "Free" flavour)
doesn't support SMP simulation so we have to switch to use of nSIM via
proprietary MetaWare debugger [1] and so:
1. We introduce new emulation target "mdb"
2. It's only possible to run that platform for those who
have MetaWare tools installed and valid license.
Though QEMU port for ARC is in work at the moment and once we
open that port and it has SMP support we'll switch to it and everybody
will be able to try ARC HS with SMP.
[1] https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The xlnx-zcu102 qemu machine is the only one that supports a Cortex-R
processor. However, its main CPUs are Cortex A53s which requires the
aarch64 qemu binary to run.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
For now we enforce the medany code model for 64-bit builds as we get
reloc issues otherwise. The instruction set and ABI are also set to
soft-float usage.
The ilp32 ABI is explicitly specified on 32-bit build to make sure
it is not using a wrong default if the same toolchain is used for both
32- and 64-bit builds. The archittecture options are the same as the
SDK's riscv32 toolchain default in that case.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
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 main change is the elimination of the bootstrapper, a design flaw
/ misfeature.
Update the documentation to be compatible with the 0.6.x releases as
well. This has to be done atomically, as there were incompatible
changes. Make use of the versionchanged and versionadded directives
to begin keeping track of how these APIs are evolving.
(Note that west 0.6.0 will remain compatible with the extension
commands in Zephyr v1.14 LTS as long as that is still alive. This
change is targeted towards Zephyr 2.0 users.)
This requires a bump in the shippable container and allows us to
simplify the west_commands test procedure.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
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>
Depending on how compiler is built, it prints a different include
directory with `--print-file-name=include`. What we want, instead, is
directories with `stddef.h` and `include-fixed/limits.h`.
This commit explicitly specify the header files we want to use, then
take the directory from the returned path.
Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
This abstracts the interface for generation of the strip command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
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 abstracts the interface for generation of the readelf command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
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 abstracts the interface for generation of the objdump command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
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 abstracts the interface for generation of the objcopy command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
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>
ARC nSIM simulates pretty much any modern ARC core,
moreover it emulates a lot of different core features so
it is possible to play with them even wo real hardware.
Thus we add yet another ARC core family to be used on simulated
nSIM board.
For now it's just a basic configuration with ARC UART for
smoke-testing of Zephyr on ARC HS CPUs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The ARC HS is a family of high performance CPUs from Synopsys
capable of running wide range of applications from heavy DPS
calculation to full-scale OS.
Still as with other ARC cores ARC HS might be tailored to
a particular application.
As opposed to EM cores ARC HS cores always have support of unaligned
data access and by default GCC generates such a data layout with
so we have to always enable unaligned data access in runtime otherwise
on attempt to access such data we'd see "Unaligned memory exception".
Note we had to explicitly mention CONFIG_CPU_ARCEM=y in
all current defconfigs as CPU_ARC{EM|HS} are now parts of a
choice so we cannot simply select ether option in board's Kconfig.
And while at it change "-mmpy-option" of ARC EM to "wlh1"
which is the same as previously used "6" but matches
Programmer's Reference Manual (PRM) and is more human-friendly.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The method for getting a memory usage report printed during build, is
based on a GNU linker (ld) option flag, and thus is not necessarily
supported by other toolchain binary tools.
The introduced cmake macro allows for a given toolchain to specify how
the memory usage report is to be generated, and whether the command for
generation, if any, is to be added to the post_build_commands and the
post_build_byproducts lists of the top level CMakeLists.txt
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 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 board and SoC was discontinued some time ago and is currently not
maintained in the zephyr tree.
Remove all associated configurations and variants from the tree.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a new DTS/binding parser to scripts/dts/ for generating
generated_dts_board.conf and generated_dts_board_unfixed.h.
The old code is kept to generate some deprecated defines, using the
--deprecated-only flag. It will be removed later.
The new parser is implemented in three files in scripts/dts/:
dtlib.py:
A low-level .dts parsing library. This is similar to devicetree.py in
the old code, but is a general robust DTS parser that doesn't rely on
preprocessing.
edtlib.py (e for extended):
A library built on top of dtlib.py that brings together data from DTS
files and bindings and creates Device instances with all the data for
a device.
gen_defines.py:
A script that uses edtlib.py to generate generated_dts_board.conf and
generated_dts_board_unfixed.h. Corresponds to extract_dts_includes.py
and the files in extract/ in the old code.
testdtlib.py:
Test suite for dtlib.py. Can be run directly as a script.
testedtlib.py (uses test.dts and test-bindings/):
Test suite for edtlib.py. Can be run directly as a script.
The test suites will be run automatically in CI.
The new code turns some things that were warnings (or not checked) in
the old code into errors, like missing properties that are specified
with 'category: required' in the binding for the node.
The code includes lots of documentation and tries to give helpful error
messages instead of Python errors.
Co-authored-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The macro, toolchain_cc_produce_debug_info, adds the compiler specific
flag for enabling the production of debugging information in the
toolchain native format.
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>
In order for CMake and Python to interact correctly when the former
invokes the latter, ensure that Python uses UTF-8 encodings when
interacting with stdout and stdin on Windows.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
We don't generate any CONFIG_ prefixed symbols from dts files so we
don't need to try and import them in anymore.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We need to pass -m64 instead of -m32 when CONFIG_64BIT is set.
This is pretty x86 centric. Many platforms don't have the ability
to select between 32-bits or 64-bits builds and either of those should
be dropped in that case with restriction on the available configuration
done elsewhere. But for the time being this allows for testing both.
Signed-off-by: Nicolas Pitre <npitre@baylibre.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>
Not all DTS changes are board specific and we should support overlays
that can be used with multiple boards. For example with a sensor, for
example:
Use this overlay for a sensor:
&arduino_i2c {
bme280@76 {
compatible = "bosch,bme280";
reg = <0x76>;
label = "BME280";
};
};
This will work with any board that has &arduino_i2c defined, but should
also work if you specify the instance directly (&i2c0 or &i2c1).
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The Particle mesh feather boards provide device-tree overlays that
allow individual applications to select the SPI peripheral to be
used for the pins associated with a specific labelled SPI device.
This is necessary because different peripheral instances have slightly
different properties.
Add BOARD_DIR to DTS_ROOTS so these shared files can be located when
included from application-specific overlays.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
sanitycheck takes any "extra_config" list found in the testcase.yaml
file and generates an "overlay" file from it. This file is placed in
the per-test build directory and passed to cmake/kconfig.cmake through a
-DOVERLAY_CONF= option set in the (also) generated sanity-out/Makefile.
This commit moves this generated config overlay to a subdirectory one
level down from the build directory, otherwise kconfig.cmake picks it
up *twice*: once from the -DOVERLAY_CONF= option already mentioned above
and a second time because kconfig.cmake scans the build directory and
blindly picks up ALL files ending with .conf[*]. The second pickup is
problematic because kconfig.cmake currently gives it the top precedence,
even higher than anything the user espressed with --extra-args=CONFIG_*
Here's a quick and simple demonstration of the issue fixed by this
commit:
cd $ZEPHYR_BASE/samples/net/sockets/net_mgmt/
sanitycheck -T. -p qemu_x86 -b -v # --extra-args=CONFIG_USERSPACE=y|n
grep CONFIG_USERSPACE $(find sanity-out/ -name .config)
.net_mgmt.kernelmode/zephyr/.config: # CONFIG_USERSPACE is not set
.net_mgmt.usermode/zephyr/.config: CONFIG_USERSPACE=y
grep 'Merged configuration' $(find sanity-out/ -name build.log)
Without this commit, attemps to override anything with
--extra-args=CONFIG_ are silently dropped on the floor.
For more background this issue was found while using the recipe in
commit message 4afcc0f8af
[*] picking up all .conf files is debatable but a much bigger debate
with backward compatibility implications. This small fix makes
absolutely zero difference to anyone or anything not using sanitycheck.
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>
This allows for inclusion of out-of-tree toolchain cmake files
relating to compiler and linker for both target and generic
toolchains.
The base path used was ZEPHYR_BASE, instead of TOOLCHAIN_ROOT, thus
making it impossible to load the out-of-tree toolchain specific
cmake files.
In addition, the generic toolchain may now specify a generic cmake
file for the linker, similar to the target toolchain 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>
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>
Commit f57ba2d30c ("cmake: toolchain_cc_imacros: don't use space
separated arguments") moved toolchain_cc_imacros() to using the long
argument format in order to avoid spaces that CMake uses to delimitate
and deduplicate arguments.
It seems that xcc doesn't support the --imacros=foo form. However
it does support the short "combined" -imacrosfoo form (without space).
So let's use that instead and document the caviat.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
target_sources() documentation states:
Relative source file paths are interpreted as being relative to the
current source directory (i.e. CMAKE_CURRENT_SOURCE_DIR).
Remove spurious code duplicating cmake's behaviour. It proved to be a
time-consuming red herring while debugging some path-related issue and
"less is more".
Signed-off-by: Marc Herbert <marc.herbert@intel.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>
Because CMake explicitly deduplicates arguments, it is not possible
to use toolchain_cc_imacros() multiple times as the later "-imacros"
are stripped away, leaving the associated file arguments dangling.
The documented workaround in the CMake manual involves some "SHELL:..."
construct but that doesn't get through zephyr_compile_options()
undammaged.
Let's simply remove this issue altogether by replacing "-imacros x.h"
with the joined form "--imacros=x.h" instead. Both gcc and clang
support this syntax.
FYI, this joined form is also available for other arguments such as:
-include x.h --> --include=x.h
-A foo --> --assert=foo
-D foo --> --define-macro=foo
-U foo --> --undefine-macro=foo
Etc.
Signed-off-by: Nicolas Pitre <npitre@baylibre.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 start of generated/cfb_font_dice.h looked like this:
/*
* This file was automatically generated using the following command:
* /home/john/zephyrproject/zephyr/scripts/gen_cfb_font_header.py
* --input fonts/dice.png --output
* /home/john/tmp/build/zephyr/include/generated//cfb_font_dice.h
* --width 32 --height 32 --first 49 --last 54
*/
For build reproduction and "privacy" reasons, change it to this:
/*
* This file was automatically generated using the following command:
* ${ZEPHYR_BASE}/scripts/gen_cfb_font_header.py
* --input fonts/dice.png --output
* zephyr/include/generated//cfb_font_dice.h
* --width 32 --height 32 --first 49 --last 54
*/
Test with:
sanitycheck -p reel_board \
-T $ZEPHYR_BASE/samples/display/cfb_custom_font/
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The macro obtains the toolchain specific flag and value for
setting of the requested c standard.
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>
Final step of linker abstraction:
* Abstract zephyr_lnk by including it in toolchain_ld_link_elf.
* Abstract relevant uses of target_link_libraries.
* Introduce toolchain_ld_force_undefined_symbols.
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 macro is intended to abstract the -fno-common compiler option
which controls the placement of uninitialized global variables. The
macro leaves it up to the toolchain to define the option.
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 macro is intended to abstract the -imacros compiler option for
inclusion of the autoconf.h header file. The abstraction allows for a
given toolchain to decide how the inclusion of the header file is to
be done.
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 macro is intended to abstract the -ffreestanding compiler option
which tells the compiler that this is a bare metal env. The option is
compiler and thus toolchain specific, but this macro leaves it up to
the toolchain to decide the value of the option.
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>
cmake has a number of issues dealing with symbolic links:
https://gitlab.kitware.com/cmake/cmake/issues/16228
One of them can cause cmake to rewrite the -S input from the user and
CMAKE_SOURCE_DIR to unexpectedly include symbolic links:
https://cmake.org/pipermail/cmake/2019-May/thread.html#69496
Catch this corner case and warn about subtle issues like breaking
-fmacro-prefix-map=${ZEPHYR_BASE}=
Sample warning message:
CMake Warning at ../../CMakeLists.txt:30 (message):
ZEPHYR_BASE doesn't match CMAKE_CURRENT_SOURCE_DIR
ZEPHYR_BASE = ~/zephyrproject/zephyr
PWD = ~/westsymlink/zephyr/samples/hello_world
CMAKE_CURRENT_SOURCE_DIR = ~/westsymlink/zephyr
You may be using a mix of symbolic links and real paths which causes
subtle and hard to debug CMake issues.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This helps by letting us add checks for when the runner has already
been set. There is documentation saying you can set
-DBOARD_DEBUG_RUNNER at the command line and have it take effect,
which turns out not to be true for a large number of boards.
A status message helps the user debug.
(We'll address the existing in-tree boards in the next patch.)
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Add a version check to allow building with older GCC versions that did
not support this option.
Fixes#16607
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
With gcc 9.1.x on fedora 30 we are getting new warnings that turn into
errors when running sanitycheck. Disable those while the issues are
being addressed.
Relates to #16587
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This is a graphical configuration interface written in Tkinter. Like
menuconfig.py, it supports showing all symbols (with invisible symbols
in red) and jumping directly to symbols. Symbol values can also be
changed directly from the jump-to dialog.
This interface should feel a lot smoother than menuconfig.py on Windows.
When single-menu mode is enabled, a single menu is shown at a time, like
in the terminal menuconfig. Only this mode distinguishes between symbols
defined with 'config' and symbols defined with 'menuconfig'.
Compatible with both Python 2 and Python 3. Has been tested on X11,
Windows, and macOS.
To avoid having to carry around a bunch of GIFs, the image data is
embedded in guiconfig.py. To use separate GIF files instead, change
_USE_EMBEDDED_IMAGES to False. The image files can be found in
https://github.com/ulfalizer/Kconfiglib/tree/screenshots/guiconfig.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Make headers look like this instead:
/* From ${ZEPHYR_BASE}/arch/common/isr_tables.ld: */
Besides being shorter and more "private", this makes the content of
snippets-*.ld files the same no matter who built them and where.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
With the addition of a local CMake variable ZEPHYR_BASE that mirrors the
value of the environment variable the documentation build broke on
Windows. This is because CMake was incorrectly interpreting backslashes
present in the Windows path as escaping characters. In order to avoid
this, use CMake's built-in file(TO_CMAKE_PATH) functionality, which
converts the path to a canonical version using forward slashes only.
At the same time rework boilerplate.cmake to use the same mechanism
instead of manually replacing backslashes and removing trailing ones.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Introducing the macro toolchain_cc_warning_error_implicit_int which,
abstracts the implicit_int error flag thus leaving it to the toolchain
to decide whether this flag is needed or not.
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 macros are named toolchain_cc_warning_error_misra_sane and
toolchain_cc_cpp_warning_error_misra_sane
These macros provide toolchain specific flag(s) relating to the MISRA
SANE configuration option.
The macros will place the flag(s) in a variable provided by caller,
which can then add to zephyr compile options.
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>
on non-XIP system, SRAM is the default region, and relocated .data
section and .bss section of SRAM shouldn't be inserted between
_image_rom_start and _image_rom_end, because the memory region between
_image_rom_start and _image_rom_end will construct the mpu ro region.
Also for the newly added memory region on non-XIP system, the
relocated .text secition and .rodata section should also be mpu aligned.
Fixes: #16090.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
'west --version' output has the path to the west manifest directory.
If there is a semantic version string in this path name, it will
raise a false version check failure.
Signed-off-by: Thomas Stilwell <Thomas.Stilwell@nordicsemi.no>
Shields can often be very complex to setup in a generic way for several
boards to support. Let's allow shields to have their own .conf files
as well as specialized overlays per board (when needed).
Signed-off-by: Michael Scott <mike@foundries.io>
Allows snippets to be placed in different locations:
- The noinit, rwdata and rodata output sections
- Two different locations for placing custom output sections,
one location for RAM and another for all other sections.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This is placeholder for extended warning flags, likely to change between
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>
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>
