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>
