When DT sources change CMake must be run again. CMake is currently
detecting changes to DT source files that we manually specify, but not
sources that are included through use of the preprocessor.
This patch makes the preprocessor output the includes used and adds
them to the 'CMAKE_CONFIGURE_DEPENDS' property.
This fixes#16791.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Added a function that can parse the dependency information given when
invoking gcc with the argument '-M'. This could be used to manually
add dependencies detected when preprocessing a file.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This commit introduces the cmake extension zephyr_library_amend.
This function allows for adding files in an out-of-tree Zephyr module
to a zephyr library created in zephyr repo CMake files.
As example:
drivers/entropy/CMakeLists.txt creates an zephyr library as:
zephyr_library()
only available to zephyr itself.
The amend function allows to amend to such a lib, by creating a
CMakeLists.txt file following identical folder structure in a Zephyr
Module:
<zephyr_module_oot>/drivers/entropy/CMakeLists.txt
zephyr_library_amend()
zephyr_library_sources() # Sources are amended to the original library
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Instead, use the QEMU_KERNEL_FILE facility to perform the
change in a new file zephyr-qemu.elf. This is what will
be sent to the emulator.
Fixes an issue where opening zephyr.elf in GDB would treat
it as a 32-bit binary instead of what it actually is,
forcing the user to override the arch setting.
Fixes: #19734
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This was a very early test and got bitrotten inside a esp32-only
whitelist. Make it run generically.
SMP must be forced off by the test (it's commonly a platform default).
Add a build-time failure when the configuration is single-CPU, for
clarity.
Filter the test likewise so it runs on all supported systems.
Also, the key argument to the CPU startup function is vestigial and
the test was being too strict by requiring it to be non-zero.
Finally, the qemu command line needs to predicate the "-smp" argument
on CONFIG_MP_NUM_CPUS and not just CONFIG_SMP so we have an extra CPU
to test against.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Putting overlay files in the test/sample root clutters the file
system. Allow them to be in the boards subdirectory alongside
board.conf files.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Fix a bug where DTS_BINDINGS_DIRS could only have one entry. When
there were more than one entry the command for invoking menuconfig
became corrupted.
This changes the separator of DTS_BINDINGS_DIR from a space to ? so
that the shell does not interpret the space as an argument separator.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
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>
Sebastian Bøe