ZBus stores observers in two ways: statically using a list and dynamically
using a memory slab. Both present limitations. Static observers work only
for channel definition. The dynamic observers rely on a memory slab that
forces the user to manage its size to avoid issues with adding
observers. This commit fixes the static allocation problem by using the
iterable sections for allocating observation data and replacing the VDED
execution sequence since now it is possible to prioritize static observer
execution. All the runtime observers are dynamically allocated on the heap
instead of a specific memory pool.
BREAK changes (only internal, not APIs):
* ZBus channel metadata changed. Remove the observers' static array
pointer. Rename the `runtime_observers` pointer to `observers`. Add
`observer_start_idx` and `observer_end_idx`;
* Change the VDED execution sequence. The position (on definition time),
the priority in conjunction with the lexical order, is considered for
static post-definition time observers. At last, the runtime observer
follows the adding sequence;
* Replace the `CONFIG_ZBUS_RUNTIME_OBSERVERS_POOL_SIZE` with
`CONFIG_ZBUS_RUNTIME_OBSERVERS`.
New APIs:
* New iterable section iterators (for channels and observers) can now
receive a user_data pointer to keep context between the function calls;
* New `ZBUS_LISTENER_DEFINE_WITH_ENABLE(_name, _cb, _enable)` and
`ZBUS_SUBSCRIBER_DEFINE_WITH_ENABLE(_name, _queue_size, enable)` that
enable developers define disabled observers. They need to be enabled
during runtime to receive notifications from the bus;
* `ZBUS_CHAN_ADD_OBS` macro for adding post-definition static observers of
a channel.
Important changes:
* Move the ZBus LD file content to the `common-ram.ld` LD file. That was
necessary to make ZBus compatible with some Xtensa and RISCV boards.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
Add a a new source coverage for native builds
and new kconfig choice of COVERAGE mode to select which:
* COVERAGE_NATIVE_GCOV: what we had until now with native builds
* COVERAGE_NATIVE_SOURCE: a new LLVM source coverage mode
* COVERAGE_GCOV: the old COVERAGE_GCOV (embedded gcov data generation).
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Adds support for absolute paths on windows, this supports the likes
of C:\, C:/ but does not support network \\ paths
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
When west is used by Zephyr, then minimum required version is 0.14.0.
Therefore cleanup west.cmake by removing code which are created to
support west versions =< 0.7.x.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Use proper --config= syntax instead of --config as the latter can cause
issues in some situations.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Export Zephyr image byproducts through `BYPRODUCT_<VAR>` cache
variables.
This allow external tools, such as sysbuild, to read information on
products produced by a Zephyr build from the image CMake cache.
For sysbuild, this means that all byproducts will be added to a phony
build target, which again allow sysbuild itself to depends on target
output and properly describe dependencies between byproducts and their
producing targets.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This enables -Wshadow to warn about shadow variables on
in tree code under arch/, boards/, drivers/, kernel/,
lib/, soc/, and subsys/.
Note that this does not enable it globally because
out-of-tree modules will probably take some time to fix
(or not at all depending on the project), and it would be
great to avoid introduction of any new shadow variables
in the meantime.
Also note that this tries to be done in a minimally
invasive way so it is easy to revert when we enable
-Wshadow globally. Source files under modules/, samples/
and tests/ are currently excluded because there does not
seem to be a trivial way to add -Wshadow there without
going through all CMakeLists.txt to add the option
(as there are 1000+ files to change).
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Board extensions are board fragments that may be present in any board
root folder, under `${BOARD_ROOT}/extensions/${BOARD}`. The board
extension directory may contain Kconfig fragments and/or devicetree
overlays. Board extensions are automatically loaded and applied on top
of board files, before anything else. There is no guarantee on which
order extensions are applied, in case multiple exist.
Board extensions may be useful in the context of Zephyr modules, such as
`example-application`. In some situations, certain hardware description
or choices can not be added in the upstream Zephyr context, but they do
in a downstream project, where custom bindings or driver classes can
also be created. This feature may also be useful in development phases,
when the board skeleton lives upstream, but other board features are not
yet present.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
CMake 3.16 find_python3 module introduced `Python3_EXECUTABLE` as
artifact specifier.
This allows Zephyr to cleanup its Python detection mechanism and thus
remove the Zephyr specific `PYTHON_PREFER` variable, which is now
deprecated.
This further improves the Python detection mechanism in Zephyr as it
allows users to specify Python3_EXECUTABLE and thereby follows CMake
documentation.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Extend zephyr_file(CONF_FILES <paths>) to take a list of paths to lookup
instead of a single path.
This remove the need of callers to do:
> foreach(p ${paths})
> zephyr_file(CONF_FILES ${p})
> ...
> endforeach()
and instead allow them to just pass the list directly to
> zephyr_file(CONF_FILES ${paths})
In addition the help text is updated with the detail that CONF_FILES can
be given an empty list. This has always been possible, but not
described.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes#56200
Add the ZephyrAppConfiguration package and update the corresponding
documentation. This adds flexibility to the CMake build configuration
by providing a workspace configuration package and an application
package, which only applies to the current application. The workspace
package stays the same as before, but the application package is
new and lives, per default, inside the application folder.
Signed-off-by: Nico Lüthi <nylnx@outlook.com>
Clear the output variable with an empty string, before appending to it.
Unsetting the variable locally is insufficient, because its value from
the parent scope or cache can still creep into the final result.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
According to the doc comment:
If using MERGE then SYSBUILD GLOBAL will get both the local and global
sysbuild scope variables (in that order, if both exist).
This stopped working in commit 8460d91e32,
when support for `zephyr_get(... VAR <multiple-variables>)` was added.
Instead of returning both values, the local sysbuild scope value would
clobber the global one. Fix this by splitting the internal `sysbuild`
scope into `sysbuild_local` and `sysbuild_global`, in that order.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Currently zephyr_code_relocate() will exit with an error if the
library does not exist. This commit adds a macro that only calls
zephyr_code_relocate() when a specific Kconfig symbol is enabled.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Add new option to use thread local storage for stack
canaries. This makes harder to find the canaries location
and value. This is made optional because there is
a performance and size penalty when using it.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add a new option to `board_check_revision` that can make specifying a
board revision optional. This makes it easier to work with boards that
can come in a base variant with extensions. For example Fanstel BLE
modules that come with/without power amplifiers.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
This tiny patch makes two improvements:
1. Preserve boolean (=n) assignments from command-line.
This fixes an issue where, if a symbol with `default y` were turned off
via command-line, e.g., `-DCONFIG_BOOT_BANNER=n`, a CMake re-run would
revert that symbol back to its default value.
To avoid this, the assignment should have been preserved in CMake cache
as `CLI_CONFIG_BOOT_BANNER:INTERNAL=n`. However, `kconfig.cmake` clears
unset variables from cache, and (=n) symbols become unset variables, so
an exception had to be made for them.
2. Discard invalid assignments from command-line.
Although `kconfig.cmake` takes care to discard assignments to symbols
which get unset by Kconfig, it wasn't handling the case where Kconfig
would keep the symbol but replace its value, making the CMake-cached
assignment invalid.
For example, this assignment:
west build . -DCONFIG_PRINTK=n
could be invalidated if PRINTK were selected by, e.g., BOOT_BANNER,
producing this warning:
PRINTK (...) was assigned the value 'n' but got the value 'y'. (...)
Still, the old value of (=n) was being cached. One way in which this was
evident was when setting an unrelated symbol in a separate invocation:
west build . -DCONFIG_MAIN_STACK_SIZE=512
the same warning for PRINTK would show up again.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This function has been working fine for parsing Kconfig fragments as
processed by Kconfiglib, but it can be made more robust for parsing
fragments from other sources, including handwritten ones.
Previously, Kconfig fragment lines of the form `# CONFIG_FOO is not set`
were ignored entirely, while lines of the form `CONFIG_FOO=n` would set
the corresponding CMake variable or target property to a literal `n`.
However, Kconfiglib treats both equivalently - as assignments to `n` -
so `import_kconfig()` should too.
Due to the fact that `.config` files output by Kconfiglib always show
disabled options as `# CONFIG_FOO is not set` (which was being ignored),
existing CMake code expects `CONFIG_FOO` to be unset. To avoid breakage,
the variable/property will now be unset explicitly by `import_kconfig()`
when it encounters either representation of `CONFIG_FOO=n`.
Moreover, for bool and tristate symbols, Kconfiglib accepts assignments
like `CONFIG_FOO=yeah`, `CONFIG_FOO=maybe`, or `CONFIG_FOO=nope`, and it
transforms the value of `CONFIG_FOO` into `y`, `m`, or `n` respectively.
This effect is now replicated in CMake.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This makes checksum calculation over Kconfig fragments more consistent,
which prevents writing a new `.config` when nothing really changes.
To explain this, consider the following sequence:
1. west build . -DCONFIG_XXXX=y -DCONFIG_YYYY=y
2. west build . -DCONFIG_YYYY=y
3. west build . -DCONFIG_XXXX=y
At (1), we set new values for XXXX and YYYY, so the `.config` changes.
At (2), we set a value for YYYY, but it's the same value as before, so
the `.config` doesn't get overwritten.
At (3), we set a value for XXXX, but it's the same value as before, so
the `.config` shouldn't get overwritten... but it does. What happened?
The reason is that the generated `extra_kconfig_options.conf` fragment,
which is included in the checksum calculation, was being populated using
two sets of CMake cache variables:
- past assignments, prefixed with `CLI_${KCONFIG_NAMESPACE}_`.
- new assignments, prefixed with just `${KCONFIG_NAMESPACE}_`.
Usually, past assignments would appear before new assignments, because
the default `${KCONFIG_NAMESPACE}` is CONFIG, which goes after CLI in
alphabetical order. As a result, the contents of EXTRA_KCONFIG_OPTIONS
at (1) and (2):
CONFIG_XXXX=y
CONFIG_YYYY=y
were not identical to its contents at (3):
CONFIG_YYYY=y
CONFIG_XXXX=y
resulting in a different checksum.
This is resolved by stripping out the CLI prefix first, then effectively
"mergesorting" the past and new assignments, before starting to populate
EXTRA_KCONFIG_OPTIONS.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
58408 fixed compilation for GCC >= 13.1. But -dumpversion's output
length depends on compile time configuration. It might only yield the
major version. So use -dumpfullversion instead, which is guaranteed to
always include major, minor and patch version.
Signed-off-by: Jan Henke <Jan.Henke@taujhe.de>
This patch adds Kconfig options to select either GNU libgcc or LLVM
compiler-rt. The 'rtlib' flag is provided in a config file, so this
patch introduces 'clang_libgcc.cfg' and 'clang_compiler_rt.cfg' which
enable appropriate library. The file is selected by concatenating
the 'clang_' prefix with library name.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Enable the possibility for boards to implement a custom `run` target in
its board.cmake to run any arbitrary commands. This is helpful for devs
who would like to add support for proprietary simulator to their boards
that can't be upstreamed.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Add an additional option to the `append` schema for appending to the
`DTS_EXTRA_CPPFLAGS` cmake cache variable, enabling finer control over
the content of devicetree files.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
For applications relocating big parts of the code with many sections,
builds were failing on Windows due to hitting the max command-line
length on that platform.
Fix this by using a file to store the dictionary passed to the python
script.
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/60994.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Clang/LLVM is natively a cross-compiler, so one set of applications can
compile code to all supported targets. The default target can be changed
using '--target' option.
CMake supports this type of compilers. To change compiling target, one
should set CMAKE_C_COMPILER_TARGET accorgindly.
The '--target' option has impact on the path to clang-rt library
returned by compiler when run with '--print-libgcc-file-name' option.
Without specifying target, Clang will return path to runtime library of
the host target (e.g. x86_64-pc-linux-gnu).
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Clang provides runtime library `libclang_rt.builtins.<arch>.a` but
`libgcc.a` is also supported.
The compiler can provide full path to the selected library using the
`--print-libgcc-file-name` option, for example:
```
/usr/lib64/clang/17/lib/baremetal/libclang_rt.builtins-armv7m.a
```
If `--rtlib=libgcc` option is provided, clang will also provide
appropriate path.
This patch replaces hardcoded `libgcc` with library name extracted from
path, so we are compatible with both libraries.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
This reverts commit f5eada5553.
Fixes#57590.
In order to fix incorrect program headers with CMAKE_LINKER_GENERATOR,
issue #59064 needs to be addressed first. Until then, revert to the
status quo from several versions back.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes an issue whereby absolute paths in libraries would have
duplicate paths in the name, causing issues in that they would
not be relocated.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This property specifies the flag used to pass the linker script filename
through the compiler front end tot he linker.
For clang, we use the general purpose linker-pass through -Wl flag with -T:
-Wl,-T as clang doesn't support -T.
For gcc, we use -T directly as this keeps the picolibc specs file from
inserting the picolibc linker script as well.
If the compiler doesn't specify a value, we continue to use -Wl,-T as
before.
Signed-off-by: Keith Packard <keithp@keithp.com>
Until now, linker-tool-gcc.h was used when LLD linker was chosen.
This causes linking issues because for GNU LD we use ALIGN_WITH_INPUT
attribute which is not available in LLVM LLD.
When using GNU LD we have to use ALIGN_WITH_INPUT to make sure that the
difference between VMA and LMA remains the same between output sections
that have different memory regions for VMA and LMA (RAM and FLASH).
With ALIGN_WITH_INPUT it's safe to do the memcpy of sections
that needs to be copied from flash to RAM in one function call:
(from z_data_copy() in kernel/xip.c)
```
z_early_memcpy(&__data_region_start, &__data_region_load_start,
__data_region_end - __data_region_start);
```
By default, LLVM LLD aligns both VMA and LMA to the same value, but
when --omagic (-N) option is provided then only the first output section
of given region has aligned LMA and the difference between VMA addresses
(0 is this is the first section) is added.
As a result the difference between LMA and VMA is constant for every
section, so this emulates ALIGN_WITH_INPUT option present in GNU LD
(required by XIP systems).
The --omagic flag is defined in cmake/linker/lld/target_baremetal.cmake
Example:
```
MEMORY {
ROM : ORIGIN = 0x1000, LENGTH = 1K
RAM : ORIGIN = 0x11000, LENGTH = 1K
}
SECTIONS {
.text 0x1000 : {
*(.text*)
} >ROM
.data.rel.ro : {
*(.data.rel.ro)
} >RAM AT>ROM
.data : {
*(.data*)
} >RAM AT>ROM
}
```
```
echo '.globl _start; _start: nop; .byte 1;'\
'.data.rel.ro; .balign 16; .byte 0;'\
'.data; .balign 32; .byte 0;' | \
llvm-mc -filetype=obj -triple=arm - -o test.o
armv7m-cros-eabi-ld.lld --sort-section=alignment -N -T script.ld \
test.o -o lld_out
```
```
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00001000 00001000 00000094 2**2
1 .data.rel.ro 00000001 00011000 00001010 000000a0 2**4
2 .data 00000001 00011020 00001030 000000c0 2**5
```
In this example the first section has lower alignment than the following
section, but with -N option the difference between VMA and LMA is the
same for .data.rel.ro and .data sections.
For comparison, using BFD linker with --omagic option results in the
following:
```
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00001000 00001000 00000094 2**2
1 .data.rel.ro 00000001 00011000 00001005 000000a0 2**4
2 .data 00000001 00011020 00001006 000000c0 2**5
```
with ALIGN_WITH_INPUT added, GNU LD adds the difference between VMA to
LMA, but doesn't align LMA of .data.rel.ro section:
```
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00001000 00001000 00000074 2**2
1 .data.rel.ro 00000001 00011000 00001005 00000080 2**4
2 .data 00000001 00011020 00001025 000000a0 2**5
```
Signed-off-by: Patryk Duda <pdk@semihalf.com>
So they depend or select on the right NATIVE_BUILD
instead of NATIVE_APPLICATION.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Cleanup ARC MWDT search path handling:
* Don't print warning if ARCMWDT_TOOLCHAIN_PATH is missing but
METAWARE_ROOT is set. Treat it as valid case and do message
with status level instead of warning.
* Make rest of the error messages more understandable for users.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
The generated scripts don't include a definition for any symbol indicating
the end of statically allocated memory (such as "_end"). Add a shared cmake
fragment, ram-end.cmake, which contains the necessary instructions to
define _end and z_mapped_end consistently to align with the other sample
linker scripts.
Signed-off-by: Keith Packard <keithp@keithp.com>
The find_package_handle_standard_args function is used in FindLlvmLld
without being imported. This may cause FindLlvmLld to fail
non-determistically based on if it's evaluated in a CMake build/process
before find_package_handle_standard_args is included.
We should include what we use. Explicitly include
find_package_handle_standard_args.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
Add a property to abstract the partial linking/rellocatable
linking for gcc ld and llvm's lld.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Device dependencies are not always required, so make them optional via
CONFIG_DEVICE_DEPS. When enabled, the gen_device_deps script will run so
that dependencies are collected and part of the final image. Related
APIs will be also made available. Since device dependencies are used in
just a few places (power domains), disable the feature by default. When
not enabled, a second linking pass will not be required.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use the "device_deps" naming scheme to emphasize we are storing device
dependencies. The fact we are using device handles to store them is an
implementation detail.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The syscall generation phase parses all header files to look
for potential syscalls, and emits all the relevant files to
enable syscalls. However, this results in all the syscall
marshalling functions being included in the final binary.
This is due to these functions being referred to inside
the dispatch list, resulting in ineffective garbage
collection during linking. Previous commits allows each
drivers and subsystems to specify which header files
containing syscalls are relevant. So this commit changes
the syscall generation to only include the syscalls needed
for the build in the syscall dispatch list and removing
various bits related to that. This allows the linker to
garbage collect unused syscall related function, and thus
reducing final binary size.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds a new cmake function zephyr_syscall_header() which
will be used in the future to limit the scope of syscalls
in the built binary. Currently this is just an empty stub
so that add zephyr_syscall_header() to kernel, subsys, etc.
without breaking the build.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
As of today MWDT toolchain in case of Zephyr may use few
tools from GNU toolchain - GNU compiler for DTS preprocessing
and objcopy for section renaming.
Currently we were trying to find any GNU compiler & objcopy
which start to cause compatibility issues for new targets -
i.e. not every objcopy knows new ARC targets.
Let's use ARC GNU tools from Zephyr SDK as we still usually
require it when building with MWDT for other tools like DTC
(device tree compiler)
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Fixes an issue with relative paths both with and without using
sysbuild where they would not be updated properly or a warning
would previously be emitted.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Configuration error:
| -- Configuring done (4.9s)
| CMake Error in CMakeLists.txt:
| Target "zephyr_interface" contains relative path in its
| INTERFACE_INCLUDE_DIRECTORIES:
|
| "include-fixed"
With GCC-13, limits.h and syslimits.h header files
are always being installed to include folder.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=be9dd80f933480
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Removed few VIF properties which are being hardcoded
Updated the script to parse source VIF XML and add information to
the output
Added optional Kconfig option to configure custom source VIF XML path
Cleaned up the code
Signed-off-by: Madhurima Paruchuri <mparuchuri@google.com>
