Change the GCC toolchain configuration to make use of the Cortex-R82
target. When Cortex-R82 was added as a GCC toolchain option, the GCC
version of the Zephyr SDK did not support Cortex-R82 tuning. Zephyr was
therefore compiled compiled for the Armv8.4-A architecture. Since Zephyr
SDK 0.15.0 (which updated GCC from 10.3.0 to 12.1.0) coupled with Zephyr
3.2, the Cortex-R82 target is supported.
The Armv8-R AArch64 architecture does not support the EL3 exception level.
EL3 support is therefore made conditional on Armv8-R vs Armv8-A.
Signed-off-by: Debbie Martin <Debbie.Martin@arm.com>
On very early stage build system needs to get access to DTC preprocessor.
MWDT has no it's own preprocessor, so here zephyr-SDK preprocessor is used.
On latest build stages zephyr-SDK objcoby also required as MWDT binutils
don't support all features. This at the same time requires that
ZEPHYR_SDK_INSTALL_DIR must be initialized with valid arch-dependent
prefix.
Zephyr-SDK requires ARCH variable to be initialized before
include "generic.cmake", but in hew HWMv2 model ARCH variable will be
initialized more later. This workaround uses any (first awailable,
independent on ARCH) toolchain from SDK for DTC preprocessing only.
For other build stages ARCMWDT will be used.
Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
Currently, clang produces a warning that the '--specs=nosys.specs' argument
is unused. Remove this flag to fix the warning as clang will generally not
honor '--specs' when targeting arm baremetal.
While this flag has been present for some time, I think this should be safe
to do. For background, clang does not seem to handle '--specs' [1] besides
possibly passing it through to GCC if GCC is used as the driver for
linking. However, whether GCC will be used for linking as a fallback
depends on the "Toolchain" [1] clang uses internally, which in turn depends
on the triple. For arm/thumb baremetal triples, the Toolchain clang uses
will not fall back to GCC to drive linking, so '--specs' will never be used
here.
I believe this behavior in clang is fairly longstanding as well (since
~2017/LLVM 5 [2]). While there isn't a minimum required clang version for
Zephyr, Zephyr currently requires lld >= 14.0.0. So, I don't think removing
this flag should impact current users (besides preventing the warning).
[1] https://clang.llvm.org/docs/DriverInternals.html
[2] https://reviews.llvm.org/D33259
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
This adds supports for flashing images with sysbuild where there
are multiple images per board to prevent using the same command per
image flash which might cause issues if they are not ran just once
per flash per unique board name. A deferred reset feature is also
introduced that prevents a board (or multiple) from being reset if
multiple images are to be flashed until the final one has been
flashed which prevents issues with e.g. security bits being enabled
that then prevent flashing further images.
These options can be set at a board level (in board.yml) or a SoC
level (in soc.yml), if both are present then the board configuration
will be used instead of the SoC, and regex can be used for matching
of partial names which allows for matching specific SoCs or CPU cores
regardless of the board being used
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This commit reverts a breaking change in CMAKE_SYSTEM_NAME introduced by
"Zephyr" back to "Generic") and removes the file
`cmake/modules/Platform/Zephyr`.
Both changes in the aforementioned PR were only introduced to ultimately
modify the value of the global CMake property TARGET_SUPPORTS_SHARED_LIBS
for the special case of building for Xtensa with LLEXT.
The modification of CMAKE_SYSTEM_NAME is considered a breaking change
because it has the potential to alter the build of any non-trivial project
that previously checked for the "Generic" system identifier as
corresponding to Zephyr - for example by doing
`if (CMAKE_SYSTEM_NAME STREQUAL "Generic")`. Such builds may now break in
many ways including silently when there is no `else()` clause with a
`message()` to alert the user that a whole configuration block had been
skipped.
In essence, that CMAKE_SYSTEM_NAME modification was only introduced in
order to have CMake to load `cmake/modules/Platform/Zephyr.cmake` which in
turn adjusted the value of TARGET_SUPPORTS_SHARED_LIBS.
But the use of a CMake platform file like this is ineffective for
non-trivial projects where one or more top level CMake `project()` calls
may happen before the first call to `find_package(Zephyr)` because in such
cases CMAKE_MODULE_PATH will not have been modified yet to contain the
path to <Zephyr_ROOT>/cmake/modules and thus no platform file will be
include by CMake.
This patch moves the conditional override of TARGET_SUPPORTS_SHARED_LIBS
needed by some archs (e.g. Xtensa) into the `kernel.cmake` module which
is known to be the first call to `project()` that enables any language and
thus the one that must come before any artifact target can be defined.
Note commit 64e7d85 added a Kconfig to specify the object type of llext
being built, so it's not tied to the arch anymore but to the
CONFIG_LLEXT_TYPE_ELF_SHAREDLIB option.
Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
Adds support for SoC overlay files which go in a ``socs`` folder
in application folders and functions similar to the ``boards``
folder, but works for SoCs instead of boards
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Adds support for a new ``socs`` folder that can be placed in
application folders and functions similar to the ``boards``
folder, but works for SoCs instead of boards
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Some third-party modules uses 'find_package(Threads REQUIRED)' to check
if threads implementation is supported.
The original implementation tries to find threads library using various
methods (e.g. checking if pthread library is present or compiling
example program to check if the implementation is provided by libc), but
it's not able to detect pthread implementation provided by Zephyr.
Signed-off-by: Patryk Duda <patrykd@google.com>
Unlike GNU ld, lld's gp relaxation is disabled by default and must be
explicitly enabled via `--relax-gp`. Pass this flag to enable gp relaxation
for lld when both linker relaxations and gp usage for RISC-V are enabled.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Add a symbol to enable GNU C Extensions. And a hidden option for
toolchains to signal GNU Extensions support.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
USB High-Speed devices must be able to operate at both High-Speed and
Full-Speed. The USB specification allows the device to have different
configurations depending on connection speed. Modify the API to reflect
USB Specification requirements on what can (e.g. configurations) and
what cannot (e.g. VID, PID) be speed dependent.
While the class configurations for different speeds are completely
independent, the actual class instances are shared between operating
speeds (because only one speed can be active at a time). Classes are
free to provide different number of interfaces and/or endpoints for
different speeds. The endpoints are assigned for all operating speeds
during initialization.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Introduce usbd_class_iter for keeping endpoint assignment variables
and the single-linked list node. No functional changes right now, but
this paves the way for independent speed specific configurations.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
set_compiler_property does not accept a TARGET argument. Only set_property
does but they are easy to confuse. This patch fixes the wrong instances of
set_compiler_property that should have been set_property.
Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
That call to enable_languages() is passed C CXX ASM which misleads the
reader into thinking that the three languages are enabled in that call but
at that point only ASM is actually because C and CXX were already
implicitly enabled by the call to project() above. The suggested change
removes the misleading C CXX arguments but we could as well make it clear
in the project() call by passing LANGUAGES C CXX.
Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
When LLEXT_REMOVE_FLAGS is empty, the regular expression that is
constructed to remove flags from the Zephyr flags would match any
string, resulting in all flags being removed. This is not the intended
behavior, so we need to handle this case by setting the regular
expression to a pattern that does not match anything.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
The partial linking option depends on the linker used in the build
process, and this flag is already defined by the Zephyr toolchains.
Use the $<TARGET_PROPERTY:linker,partial_linking> generator expression
to retrieve it instead of hardcoding the value for the GNU linker.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
Some toolchains may generate convoluted paths when reporting accessory
tools. This is the case with GCC in the Zephyr SDK toolchain. For
example, for a Zephyr SDK installed under `C:\Portable\Zephyr` a call to
`gcc --print-prog-name=ld.bfd` should normally return something like
`c:/portable/zephyr/zephyr-sdk-0.16.5/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe`
but because of how the toolchain was created the path reported gets all
messed up with relative fragments. In above case, the actual path reported
was `c:/portable/zephyr/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe`
One might argue that this should be fixed in the toolchain which could be
possible for the Zephyr SDK but not for other toolchains (definitely not
for proprietary ones).
Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
Adds a new variable NORMALIZED_BOARD_QUALIFIERS which contains
the board qualifiers in file-name format, this allows for
constructing strings in applications (e.g. for folder names) prior
to Zephyr being found for things like APPLICATION_CONFIG_DIR. Also
adds NORMALIZED_BOARD_TARGET.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fixes: #71384
A VERSION file placed in `/` or `<drive>:\` was accidentally being
picked up during `find_package(Zephyr)`.
This happened because Zephyr loads the VERSION file to determine if it
is the correct Zephyr to use.
During initial phase of find_package(), then APPLICATION_SOURCE_DIR is
not defined, causing one version file to be picked up from `/VERSION`
instead of `<app>/VERSION`. `/VERSION` is outside any Zephyr repo, west
workspace, or the application itself and therefore should not be picked
up accidentally.
Fix this be checking that APPLICATION_SOURCE_DIR is defined, and only
when defined, look for a VERSION file there.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fix issue #67244 in which boards from external modules where not
printed in the help message (displayed for `shields` target or
when trying to build with unknown shield). The SHIELD_LIST variable
was reset for each BOARD_ROOT discovered.
Simplify discovery logic. Discover all shields and set relevant
variables (SHIELD_LIST and SHIELD_DIR_${name}) in one step and
process all the expected boards in the next step.
Signed-off-by: Marek Metelski <marek@metelski.dev>
This commit adds support for building relocatable (partially linked)
ELF files as the binary object type for the llext subsystem.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
This change allows the `add_llext_target` function to accept multiple
source files when building an ELF shared library. The ELF object
target type is still limited to a single source file, since there is no
linking step in that case.
Also fixes a minor typo in another llext function documentation.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
Add a new Kconfig option to select the binary object type for the llext
subsystem. This will allow to fully decouple the architecture type from
the kind of binary object that is expected by the loader.
The defaults have been chosen to match the current behavior of the ARM
and Xtensa architectures, but developers can now more easily experiment
with other object types.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
This allow developers to create board files without the SoC name when
the board only defines a single SoC.
This means that a board, such as rpi_pico, which defines only a single
SoC, rp2040, and one variant, now allows the following file names:
Board target: rpi_pico/rp2040
- dts: rpi_pico_rp2040.dts, short: rpi_pico.dts
- defconfig: rpi_pico_rp2040_defconfig, short: rpi_pico_defconfig
- overlay: rpi_pico_rp2040.overlay, short: rpi_pico.overlay
- conf: rpi_pico_rp2040.conf, short: rpi_pico.conf
Board target: rpi_pico/rp2040/w
- dts: rpi_pico_rp2040_w.dts, short: rpi_pico_w.dts
- defconfig: rpi_pico_rp2040_w_defconfig, short: rpi_pico_w_defconfig
- overlay: rpi_pico_rp2040_w.overlay, short: rpi_pico_w.overlay
- conf: rpi_pico_rp2040_w.conf, short: rpi_pico_w.conf
A multi CPU cluster board, nrf5340dk:
Board target: nrf5340dk/nrf5340/cpunet
- dts: nrf5340dk_nrf5340_cpunet.dts, short: nrf5340dk_cpunet.dts
- defconfig: nrf5340dk_nrf5340_cpunet_defconfig,
short: nrf5340dk_cpunet_defconfig
- overlay: nrf5340dk_nrf5340_cpunet.overlay,
short: nrf5340dk_cpunet.overlay
- conf: nrf5340dk_nrf5340_cpunet.conf, short: nrf5340dk_cpunet.conf
A multi SoC board, nrf5340dk (real: nrf52840, emulated: nrf52811):
Board target: nrf52840dk/nrf52840
- dts: nrf52840dk_nrf52840.dts, short: Not possible
- defconfig: nrf52840dk_nrf52840_defconfig, short: Not possible
- overlay: nrf52840dk_nrf52840.overlay, short: Not possible
- conf: nrf52840dk_nrf52840.conf, short: Not possible
If two conflicting files are found, for example both
rpi_pico_rp2040.overlay and rpi_pico.overlay, then an error is raised.
If short form is detected for a board target with multiple SoCs, for
example nrf52840dk_nrf52840.overlay and nrf52840dk.overlay, then an
error is raised.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This change reverts a change that was introduced with hwmv2 which
allowed for using common board names for overlays, given the board
target ``nrf9160dk@0.7.0/nrf9160/ns``.
In hwmv1 this would have used:
``nrf9160dk_nrf9160_ns.conf``.
``nrf9160dk_nrf9160_ns_0_7_0.conf``.
In hwmv2 this would have used:
``nrf9160dk_nrf9160_ns.conf``
``nrf9160dk_nrf9160_ns_0_7_0.conf``
``nrf9160dk_nrf9160.conf``
``nrf9160dk_nrf9160_0_7_0.conf``
``nrf9160dk.conf``
``nrf9160dk_0_7_0.conf``
With these changes, the following are used (which restores the hwmv1
behaviour):
``nrf9160dk_nrf9160_ns.conf``
``nrf9160dk_nrf9160_ns_0_7_0.conf``
For a board with a default SoC which is not a variant for example
``rpi_pico`` then ``rpi_pico.conf`` will also be used, this file
will not be used for variants e.g. ``rpi_pico/rp2040/w``
This applies to .dts, .conf and .overlay files in the boards
directory, and to .conf and .overlay files in application board
overlay directories.
This revert is needed to avoid issues whereby variants have
incompatible configuration to the parent board target, which has
been affecting samples and tests.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Add a new CMake helper to add new include directories to be parsed by
the syscall machinery. This helper complements the existing
zephyr_syscall_header, which works at a header-level.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Instead of INTERFACE_INCLUDE_DIRECTORIES, because header files are used,
not directories. Headers were added to both, target sources and include
directories.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
This patch adds support for custom commands to be executed during the
build of an llext target. The commands can be executed at different
points in the build process:
- PRE_BUILD: Before the llext code is linked.
- POST_BUILD: After the llext code is built, but before packaging
it in an .llext file.
- POST_PKG: After the llext file has been created.
Note that PRE_BUILD is not supported for ARM targets, as in that case
object files are used directly and there is no actual linking step.
The commands can be added using the new add_llext_command() function.
An example usage of it, along with some target properties, is added to
the hello_world test case.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
Remove the C_FLAGS argument from add_llext_target() and add a set of
functions to configure the compilation and linking of an llext using
the same API of the target_* functions.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
This change reworks the Xtensa support in llext to use CMake's native
shared library support, instead of manually running "gcc -shared".
This change minimizes the differences in llext handling by defining
appropriate CMake targets for the different architectures.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
When CONFIG_LLEXT is enabled, the Zephyr platform needs to enable dynamic
library support. This is done by setting the `TARGET_SUPPORTS_SHARED_LIBS`
property to `TRUE` in the global property scope.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
Let find_program in codechecker/sca.cmake search for both 'CodeChecker'
and 'codechecker'. Before this change, I wasn't able to run CodeChecker
because cmake couldn't find it. (Ubuntu 23.10, CodeChecker 6.21.0 installed
via snap)
Signed-off-by: Benedikt Streicher <streicher.b@posteo.de>
Differently from other libraries, which are included whole in the final
Zephyr ELF, libkernel.a itself isn't. Assuming this is intended to
enable optimisations (if it isn't, this patch will break things) - linker
can remove parts of the kernel that are not used by the application.
However, when considering Linkable Loadable Extensions (llext), this
optimisations can be counterproductive: for instance, syscalls that are
not used by the application won't be available for extensions. It won't
matter if someone "EXPORT_SYMBOL" for them, or even try to keep them
using LINKER_KEEP, they'll be gone.
To avoid that, this patches includes, when CONFIG_LLEXT=y, libkernel.a
inside the linker "whole-archive" block. This ends up making it consider
libkernel.a as a library whose all symbols should be kept. Note this
doesn't mean that all symbols will be there - things compiled out via
Kconfig will naturally still be out.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Detecting this requires `boards.cmake` being able to handle multi-line
output from `list_boards.py`. Implement a similar line reading loop to
the one used in `hwm_v2.cmake`.
Failing to handle this could result in an incorrectly parsed list of
valid board qualifiers. Here's the expected list for `nrf52_bsim`:
- "native"
and here's what would happen if two copies of that board were found:
- "native\nNAME"
- "nrf52_bsim"
- "native"
Instead of that, there would now be a proper error message listing all
board directories which contain `nrf52_bsim`.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes: #69329
The board name was printed as part of printing board qualifiers because
those was being concatenated in the `board_v2_qualifiers()` method.
Keep the qualifiers separated from the board name and let the caller
concatenate the strings when required.
Completion scripts are also updated to handle the corrected behaviour.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
(cherry picked from commit 66b475a3aa)
Fixes: #69840
Add CMake configure dependency on the board's board.yml file.
This dependency ensures that CMake will re-run and pickup any changes
to the current board's board.yml file.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #69329
The board name was printed as part of printing board qualifiers because
those was being concatenated in the `board_v2_qualifiers()` method.
Keep the qualifiers separated from the board name and let the caller
concatenate the strings when required.
Completion scripts are also updated to handle the corrected behaviour.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Replace `FILE` with `ZFILE` as the prefix for `cmake_parse_arguments()`.
This is because `zephyr_file()` accepts `SUFFIX` as function argument,
and it should not be accessible as `FILE_SUFFIX` as it would conflict
with the CMake cache variable of the same name. Accessing the argument
as `ZFILE_SUFFIX` prevents the cached value from slipping into the
function scope.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
When building with `-DBOARD=plank -DFILE_SUFFIX=foo`, the build system
could set `DTC_OVERLAY_FILE` to one of:
- boards/plank_foo_foo.overlay
- boards/plank_foo.overlay
- boards/plank.overlay
The first choice is a bug, as the suffix should only be applied once.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Follow-up: fe25709a9c twister: add unit_testing soc and board
Moving the soc.yml and board.yml to subsys/testsuite tree.
Introduce subsys/testsuite/arch/archs.yml with unit_testing arch.
Update the Zephyr CMake module unittest.cmake to include HWMv2 and
reorder includes to follow same order as zephyr_default.cmake.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #69785
The boards_legacy sub-folder was temporarily introduce in collab-hwm
branch during porting to HWMv2.
This should have been removed before merging collab-hwm to main as it
prevent looking up boards in oot roots.
Removing the temporary sub-folder for HWMv2.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Followup: #69905
Adopting new board terminology for CMake, python, and Kconfig code to
use qualifiers instead of identifiers.
Also adjusted to board target where applicable.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Hardware model v2 allows the usage of <board>_<revision>.overlay and any
valid <board>_<identifier>_<revision>.overlay dts overlays in the board/
directory but CMake was only looking for the most specific
<board>_<identifier>_<revision>.overlay overlay file.
This commit allows CMake to look for the presence of any allowed overlay
file to fix this issue.
Tested by building the hello_world sample with the Olimex board
lora_stm32wl_devkit revision C.
The following line wasn't appearing before in build log and now does:
"-- Found devicetree overlay: <path>/olimex_lora_stm32wl_devkit_C.overlay"
Signed-off-by: Johan Lafon <johan.lafon@syslinbit.com>
Add a cmake check to ensure the simulator is new enough and guide
users to update it and rebuild if it isn't,
so they get a better experience than by just getting a build or
runtime error.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Rename the internal input callback structure to input_callback. This is
for coherency with "INPUT_CALLBACK_DEFINE" and other similar code paths
in Zephyr, and also to avoid confusion with terminology.
This is an internal structure, applications should not have any
references to it so there should be no need for any release note
entries.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
clang and lld support TLS for RISC-V, so advertise this support in
Kconfig. I believe other non-RISC-V targets also have TLS support in LLVM,
but I'm not sure on the exact subset. As TLS support in LLVM wasn't
automatically advertised previously, gate this on RISC-V for now as it
a) shouldn't break other targets and b) prevents us from improperly
claiming support for unsupported targets.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Ensure --target and -march/-mabi/-mcmodel are set appropriately when
building with clang targeting RISC-V.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
The analyze step for codechecker can have errors. These are printed out
to the console, allow to keep processing results for other succeeded
analysis.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
The simple test is there to test the API and simple extensions in
unison. Hello world was intended to be the first not the only extension
being tested.
Also refactors the entry thread to allow for usermode potentially by
passing the pointer to the function symbol rather than having it look it
up directly.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
lld gained support for the --print-memory-usage flag somewhat recently
(May 2023). Associate this flag with the memusage property when building
with lld, similar to what is done for GNU ld.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
If board `plank` was deprecated, then building with `-DBOARD=plank/foo`
would fail, so as to discourage identifier misuse. However, `plank/foo`
could actually be a valid target in HWMv2, so this was a bad idea.
Replace the offending error with more open-ended identifier handling,
originally suggested in #68940 (anchor: #discussion_r1492103361).
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
The exact set of environment variables required by xt-xcc and xt-clang
is a bit of a dark magic and error-prone. TOOLCHAIN_VER is definitely
one of them and the error message was puzzling when TOOLCHAIN_VER was
undefined or not exported.
- Add TOOLCHAIN_VER to the list of variables in the error message
- Replace the vague "toolchain not found" in the error message with the
more useful "XCC/install/tools//XtensaTools/bin/xt-xcc not found" where
the double slash and comparison with the filesystem clearly point at
where TOOLCHAIN_VER is missing.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Adds a deprecation notice if a file is found which has the build
type informing the user of the replacement
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Adds supports for sysbuild loading project-specific Kconfiguration
fragments that are suffixed with the user-provided value
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Adds a function that can be used to check if a file suffix is
supplied and, if so, will update a variable with these filenames
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Extend zephyr_file(CONF_FILES ...) to take a NAMES list of file names
to find instead of creating file names based on board and revision.
This allows to unify lookup prj.conf and <board>/app.overlay for
application, as well as pave the way for future enhancements to
configuration file handling.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit adds Parasoft C++test as a Static Analyser using Zephyr's SCA
framework.
By specifing -DZEPHYR_SCA_VARIANT=cpptest to west build, a cpptestscan.bdf
file will be generated under builddir/sca/cpptest/.
Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
This commit enhances the clarity of the build log by adding the "SCA"
prefix to the "Found" messages generated by sca/*/sca.cmake. This change
improves the readability of the `west build` log for users who may not be
familiar with these tools, providing more informative and understandable
output.
Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
Fixes: #68360
This commit introduces <type>_VERSION_TWEAK_STRING which includes
the tweak field in the string, but without the extra version.
This format is used by MCUboot / imgtool, and thus makes it easier to
align code to the format used by MCUboot.
This commit also introduces <type>_VERSION_EXTENDED_STRING which
includes the tweak field in the string in addition to the extra version
field.
The new defines / variables is available in code, CMake, and Kconfig,
and it defined for KERNEL, APP, and custom types, such as MCUBOOT.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
The paths that got assigned to these variable don't quite match
the description, likely a typo, fix that.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Too many times, code is pushed that includes floats that really
becomes doubles and C implicit promotion rules will want to make
floats into doubles very easily. As zephyr primarily targets
low-end process that may not have a double precision floating
point unit, enable this flag globally for now.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
If an ld file is included multiple times using `zephyr_linker_sources`,
only the last occurrence is actually used. Everything else is removed
again from the generated snippet files.
This allows to relocate certain blocks, e.g. the vector table, in an
application-specific CMakeLists.txt (or for an arch or soc).
Fixes: #66315
Signed-off-by: Greter Raffael <rgreter@baumer.com>
Enable GCC builtin static analysis in Zephyr's static code analysis
(SCA) infra.
When this option is enabled GCC performs a static analysis and
can point problems like:
sample.c
+ int *j;
+
+ if (j != NULL) {
+ printf("j != NULL\n");
output:
${ZEPHYR_BASE}/samples/userspace/hello_world_user/src/main.c:30:12:
warning: use of uninitialized value 'j' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
30 | if (j != NULL) {
| ^
'main': events 1-2
|
| 25 | int *j;
| | ^
| | |
| | (1) region created on stack here
|......
| 30 | if (j != NULL) {
| | ~
| | |
| | (2) use of uninitialized value 'j' here
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This tests whether there actually is an itcm or dtcm in the device tree.
Otherwise a FATAL_ERROR is generated.
Signed-off-by: Greter Raffael <rgreter@baumer.com>
This allows to link code and data blocks, e.g. the vector table, into
tightly coupled memory using `zephyr_linker_sources`.
Signed-off-by: Greter Raffael <rgreter@baumer.com>
Since v3.13, CMake has supported math(... OUTPUT_FORMAT <format>), which
will perform the same functionality as to_hex().
Signed-off-by: Attie Grande <attie.grande@argentum-systems.co.uk>
Since v3.13, CMake has supported math(... OUTPUT_FORMAT <format>) and 0x
prefixes on numbers, which together provides the same functionality as
to_hex() and from_hex() that we've previously maintained.
Users should switch to using math() instead, and our functions are now
marked as deprecated.
Signed-off-by: Attie Grande <attie.grande@argentum-systems.co.uk>
Previously, `to_hex(0 output)` would have placed `0x` into the `output`
variable, which is undesirable... this fix ensures that `0x0` is placed
into this variable if the input is zero.
Signed-off-by: Attie Grande <attie.grande@argentum-systems.co.uk>
Minimize the amount of flags that are hardcoded in the llext.cmake
module by moving them to the compiler specific cmake files.
The llext.cmake module will now use the new LLEXT_REMOVE_FLAGS and
LLEXT_APPEND_FLAGS global variables to adjust the set of flags used
to compile the llext code. This will make it easier to add support
for new architectures and compilers.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
Separate the compilation of the source file from the conversion to an
llext file. This allows to reuse the include directories and macro
definitions of the current Zephyr build while compiling the llext source.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
This patch defines a generic function that encapsulates all the
architecture-specific machinery needed to compile llexts from source
files. Current tests are updated to use this function.
Output and source files must be specified using the OUTPUT and SOURCES
arguments. Only one source file is currently supported.
Arch-specific flags will be added automatically. The C_FLAGS argument
can be used to pass additional compiler flags to the compilation of
the source file.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
8cc716792a renamed this variable to lower
case to indicate it's only used locally however WEST_ARG is used as a
parameter of zephyr_module.py in CMakeLists.txt when
CONFIG_BUILD_OUTPUT_META is enabled.
This variable was used when west had some limitation. It does not
really make sense now, so it has been removed and content of west_arg
variable has been added by default.
Signed-off-by: Thomas Gagneret <tgagneret@witekio.com>
Fix an issue where updating a `zephyr_code_relocate()` call in CMake
didn't trigger regeneration of `code_relocation.c` and linker scripts.
The generation command was missing a dependency on the aforementioned
input text file, where the outcome of each call is cached.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
When using the code and data relocation feature, every relocated symbol
would be marked with `KEEP()` in the generated linker script. Therefore,
if any input files contained unused code, then it wouldn't be discarded
by the linker, even when invoked with `--gc-sections`.
This can cause unexpected bloat, or other link-time issues stemming from
some symbols being discarded and others not.
On the other hand, this behavior has been present since the feature's
introduction, so it should remain default for the users who rely on it.
This patch introduces support for `zephyr_code_relocate(... NOKEEP)`.
This will suppress the generation of `KEEP()` statements for all symbols
in a particular library or set of files.
Much like `NOCOPY`, the `NOKEEP` flag is passed to `gen_relocate_app.py`
in string form. The script is now equipped to handle multiple such flags
when passed from CMake as a semicolon-separated list, like so:
"SRAM2:NOCOPY;NOKEEP:/path/to/file1.c;/path/to/file2.c"
Documentation and tests are updated here as well.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
There are some situations like #67035 where sparse aborts and returns an
error code before the compiler has generated the .obj file; without any
clear indication that the .obj is missing (in normal situations sparse
prints warnings and _does_ creates the .obj file)
Also, builds are parallel by default and sparse runs tend to be massive
walls of text which all conspires to make it totally impossible to find
the relevant error message. Instead, we get an link-time error.
The only clear indication is the exit code. So catch it and abort the
build ASAP thanks to COMMAND_ERROR_IS_FATAL.
More generally speaking, the default behavior of execute_process() to
ignore errors is crazy. How frequently does a build system run commands
that do NOT matter?
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Set align to 1 for CONFIG_MCUBOOT_IMGTOOL_OVERWRITE_ONLY,
used by non-swap update modes.
Fix imgtool error message for device with write size > 32B.
Signed-off-by: Andrej Butok <andrey.butok@nxp.com>
_FORTIFY_SOURCE=1 differs from _FORTIFY_SOURCE=2 only in the bounds
checking mode that it uses.
With _FORTIFY_SOURCE=1, bounds checks are 'loose', allowing access to the
whole underlying object, not just the subset referenced in the expression
(e.g, the bounds of a struct member is the whole struct, not just the
member).
With _FORTIFY_SOURCE=2, bounds checks are strict, meaning that the bounds
of an expression are limited to the referenced value.
Both of these perform their checks at runtime, calling _chk_fail if the
bounds check fails. That's done in the __*_chk functions included in the C
library. These are always called when _FORTIFY_SOURCE > 0, unless the
compiler replaces the call with inline code.
GCC already does all of the compile-time bounds checking for string and mem
functions when not using -ffreestanding, so there's nothing we need to add
for that to work. That means the security_fortify_compile_time property
should be empty.
Signed-off-by: Keith Packard <keithp@keithp.com>
Changes shield processing order from being on a root-by-root
basis to being order they were supplied to cmake
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Replace mutexes with semaphores to protect the channels in conjunction with
a priority boost algorithm based on the observers' priority.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
Update description of board_runner_args() function so that it is
described that app_set_runner_args macro must be defined before the call
to `find_package(Zephyr)`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
ERROR_QUIET should be used only when the command is actually expected to
fail, otherwise discarding stderr can be extremely time-consuming. See
recent example of time lost in commit 40c2e08e82 ("xcc/cmake: don't
discard stderr; don't (ever!) use ERROR_QUIET")
If some Python interpreter cannot even evaluate `sys.version_info[:2]`,
then we definitely don't want to hide what its stderr says about that.
Fixes commit 94de3e9f60 ("cmake: FindPython3: Adjust python3 program
search")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>