After having resolved all of the instances of packed member access,
re-enable the warning.
Fixes#16587.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Remove the `NAME` function argument from `zephyr_linker_dts_memory` as
the name is now automatically derived from the devicetree node.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the linker script generator to automatically derive memory
region names from the devicetree node according to the same logic in
`devicetree_regions.h`.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
This causes any devicetree error messages to refer to the source files
which contain the errors instead of intermediate <BOARD>.dts.pre.tmp
files in the build directory.
Do this using a new python-devicetree feature which can correctly
handle cpp's generated line marker directives.
To use this feature, rework the way that the C preprocessor is run on
devicetree inputs so that line marker directives are preserved by
removing the -P option.
This is a backwards incompatible change to the way the generated files
in the build directory used to work, as not all tools can consume line
markers. In particular, dtc can't handle these lines. We therefore
pass dtc zephyr.dts instead (the final parsed devicetree output from
python-devicetree).
Since <BOARD>.dts.pre.tmp is a publicly documented file, this is
changing existing behavior, so use a new file name for the
intermediate files to make it more obvious that something changed. In
particular, use zephyr.dts.pre instead of <BOARD>.dts.pre.tmp.
(The $BOARD.dts.pre.tmp name is a little cumbersome anyway.)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Curently, any and all devicetree syntax errors are being handled by
dtc, because it runs before gen_defines.py. This means that any
improvements we make to devicetree error handling and reporting in
dtlib or edtlib will never be noticed by users that have dtc
installed.
(This also has the unfortunate effect of hiding dtlib error reporting
from me, since my systems all have dtc installed.)
Move dtc to after gen_defines.py, so that initial error handling and
warnings all come from python. If DTC has some additional warnings or
errors to report, let them come last. They will still halt the build
if anything is wrong.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
When multiple shields are defined, only the shield last in the -DSHIELD
list gets defined in `.config`. This is due to too many backslashes
used defining it for an env setting.
Signed-off-by: Ryan McClelland <ryanmcclelland@fb.com>
In the python APIs we use for devicetree, you can generally use an
alias interchangeably with the full path to a node.
For example, dtlib.py says:
[...] both dt.get_node("/foo/bar") and dt.get_node("bar-alias")
will return the 'bar' node below:
/dts-v1/;
/ {
foo {
bar_label: bar {
baz {
};
};
};
aliases {
bar-alias = &bar-label;
};
};
Fetching subnodes via aliases is supported:
dt.get_node("bar-alias/baz") returns the 'baz' node.
Now that we have the necessary helper functions for resolving alias
names, make the CMake APIs to devicetree behave the same way. This
improves consistency between the two sets of devicetree helpers used
by the build system, making them both match the general devicetree
practice that an alias is as good as a path. This is good for
consistency.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a helper function for looking up the path to a devicetree
alias. It is analogous to dt_chosen(). It has to exist as a separate
function from dt_prop() for similar reasons that dt_chosen() does:
the edtlib APIs for interacting with /aliases are special-cased in the
same way they are for /chosen.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes an issue on SOF-supported boards where the build system
incorrectly believed that the rimage target was changing when rerunning
CMake, even though the user did not change any configuration. This issue
was introduced in commit 525fa76f4d.
Create initial build dir:
$ west build --board intel_adsp_cavs18 samples/subsys/audio/sof
Re-run CMake with no arguments in that build dir:
$ cd build
$ cmake .
CMake Warning at /home/mhelm/zephyrproject/zephyr/cmake/extensions.cmake:2403 (message):
The build directory must be cleaned pristinely when changing rimage target,
Current value="", Ignored value="cnl"
Call Stack (most recent call first):
/home/mhelm/zephyrproject/zephyr/cmake/extensions.cmake:829 (zephyr_check_cache)
/home/mhelm/zephyrproject/zephyr/boards/xtensa/intel_adsp_cavs18/board.cmake:6 (board_set_rimage_target)
/home/mhelm/zephyrproject/zephyr/cmake/app/boilerplate.cmake:635 (include)
/home/mhelm/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
/home/mhelm/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
CMakeLists.txt:5 (find_package)
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Create the ZEPHYR_MODULES_NAMES list of zephyr modules present in the
system before calling roots defined in `MODULE_EXT_ROOT`.
This will allow external module roots to process based on Zephyr modules
available in the system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #40590
This commit updates gen_app_partitions.py to include only files present
in the current build by extracting the information from the CMake
generated `compile_commands.json` file.
This ensures that object files in sub-projects, such as `empty_cpu0`,
will not be considered by the script.
Using the compile_commands.json instead of walking the whole build tree
for finding object files also improves performance:
Time of executing `gen_app_partitions.py` (Old):
__________________________
Executed in 480.06 millis
usr time 425.83 millis
sys time 49.55 millis
Time of executing `gen_app_partitions.py` (New):
________________________________________________________
Executed in 76.22 millis
usr time 49.00 millis
sys time 24.59 millis
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
boilerplate.cmake contained a comment referring to CMake 3.13.1 but
minimal required version is 3.20, so update the comment to 3.20.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Removes hardcoded logic in the west signing script that translates
Zephyr board names to rimage target names. Instead, use a cached CMake
variable set at the board level to define its respective rimage target
name. This eliminates the need to modify the west signing script when
new SOF-supported boards are introduced to Zephyr.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
DTC can be built with both traditional Makefiles or Meson. When built
with Makefiles the --version output looks like 'Version: DTC
1.6.1-dirty' but when built with Meson the output is 'Version: DTC
v1.6.1+.
This fails to match the version regex and the cmake then fails:
CMake Error at cmake/host-tools.cmake:28 (if):
if given arguments:
"VERSION_GREATER" "1.4.6"
Unknown arguments specified
Expanding the regex with an optional 'v' covers both cases and the build
succeeds.
Signed-off-by: Ross Burton <ross.burton@arm.com>
This commit reworks the linker script generation and linking stages in
order to better support fixed section location as required by #38836.
Today we have the following generated linker scripts and the elf output
depending on the system configuration:
- linker_app_smem_unaligned.cmd --> app_smem_unaligned_prebuilt.elf
- linker_zephyr_prebuilt.cmd --> zephyr_prebuilt.elf
- linker.cmd --> zephyr.elf
as not all linker scripts may be created and as there is a need for the
possibility to move gen handles earlier then those stages has been
renamed into more generic names so that with this commit we have:
- linker_zephyr_pre0.cmd --> zephyr_pre0.elf
- linker_zephyr_pre1.cmd --> zephyr_pre1.elf
- linker.cmd --> zephyr.elf
This also means that is the stage zephyr_pre1 is not needed, then build
can go from `zephyr_pre0.elf` to `zephyr.elf`.
The gen_handles.py has been changed so it now uses `zephyr_pre0.elf` as
input. This ensures that the handles array are final when invoking the
next build and linking stages.
To keep the current behavior of generating the isr table and kobj hash
of what was `zephyr_prebuilt` stage the code blocks contolling isr
generation and kobj hash has been relocated to be located after
app_smem and device handle generation.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Introduce a new global property for source files that are generated from
the initial Zephyr link (app_smem_unaligned_prebuilt). This source list
is used for files which will introduce address shifts into the final
binary, which need to be present in `zephyr_prebuilt.elf` for
`CONFIG_USERSPACE` scripts to correctly generate `zephyr.elf`.
This resolves#38836.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
The previous description of the `GENERATED_KERNEL_*` cmake variables
was incorrect in that these are generated after the second link stage
when `CONFIG_USERSPACE` is enabled.
The sources in these variables are generated from `zephyr_prebuilt.elf`
for inclusion in `zephyr.elf`. However `zephyr_prebuilt.elf` is preceded
by `app_smem_unaligned_prebuilt.elf` when `CONFIG_USERSPACE` is enabled.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Currently there is no way to support running a board on multiple
emulation platforms nor to choose a desired emulation platform for the
simulation to be run on. This commit introduces a new
SUPPORTED_EMU_PLATFORMS list, which defines available emulation
platforms for a given board.
Fixes#12375.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
This commit is motivated by the west discussion in:
https://github.com/zephyrproject-rtos/west/issues/548
The commit provides the ability to generate a build meta info file
containing lists of:
- Zephyr: path and revision
- Zephyr modules: name, path, and revision
- West: manifest path
path and revision for each project
For Zephyr or Zephyr modules the revision will be `null` if it is not
under git version control.
If Zephyr, a modules, or a project has uncommitted changes, the revision
will be marked dirty.
If west is not installed or used for the build process, the
west-projects list will be empty.
If a project is both a Zephyr module and a west project it will show up
in both lists.
Similar to Zephyr, which is independently referred as the Zephyr in use
but also listed as west project when west is used.
This is important in case ZEPHYR_BASE was manually set and pointing to
a different Zephyr repository.
The build meta file is not created per default but can be enabled with
the BUILD_OUTPUT_META Kconfig setting.
A project using west and having an extra Zephyr module loaded not
controlled using git can look like:
zephyr:
path: /.../zephyr
revision: 863600cd0e3c0a271e86629c5089821e5e4380cc-dirty
modules:
- name: mcuboot
path: /.../bootloader/mcuboot
revision: c61538748ead773ea75a551a7beee299228bdcaf
- name: local_module
path: /.../local_module
revision: null
west:
manifest: /.../zephyr/west.yml
projects:
- path: /.../zephyr
revision: 863600cd0e3c0a271e86629c5089821e5e4380cc-dirty
- path: /.../bootloader/mcuboot
revision: c61538748ead773ea75a551a7beee299228bdcaf
- path: /.../tools/net-tools
revision: f49bd1354616fae4093bf36e5eaee43c51a55127
And without west:
zephyr:
path: /.../zephyr
revision: 863600cd0e3c0a271e86629c5089821e5e4380cc-dirty
modules:
- name: hal_nordic
path: /.../modules/hal/nordic
revision: a6e5299041f152da5ae0ab17b2e44e088bb96d6d
west: null
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
With this commit a dedicated APPLICATION_CONFIG_DIR is added to the
Zephyr build system.
Currently, the APPLICATION_SOURCE_DIR is identical also the base
location of configuration files.
This is very practical for simple samples, but also has it limitations
for more complex setups.
Introducing a dedicated APPLICATION_CONFIG_DIR allows users more
customization options in Zephyr build system.
Especially in terms of custom build configuration files unknown to
Zephyr itself.
For example, instead of all configuration files being located directly
in the application source folder, a project might prefer to organize
their configuration files on a per board basis, for example:
<app>/boards/custom_board_A/prj.conf
<app>/boards/custom_board_A/app.overlay
<app>/boards/custom_board_A/custom_file.mine
<app>/boards/custom_board_B/prj.conf
<app>/boards/custom_board_B/app.overlay
<app>/boards/custom_board_B/custom_file.mine
...
instead of n-files located in the root of the sample.
If the user / sample specifies APPLICATION_CONFIG_DIR, then this folder
will always be used instead of the default configuration folder.
As part of this extension the behaviour of
`-DCONF_FILE=<relative-path>/prj_<build>.conf` and additional Kconfig
fragments automatic sourcing has been aligned with the default behavior
of `prj.conf`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The `merge_config_files` list contains files with both relative and
absolute paths.
Each entry is checked and files with a relative path are converted to
absolute path. This creates a `merge_config_files_with_absolute_paths`
identical to the `merge_config_files` but with absolute path on each
entry.
Afterwards it is mixed whether `merge_config_files` or
`merge_config_files_with_absolute_paths` are used creating unnecessary
risk when the list with relative path files are used.
This commit sets the content of `merge_config_files` with updated
absolute paths files, and also updates all places to use this list.
This ensures that after path conversion then only the list with absolute
paths is used.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
To prepare for linker script creation with flexible number of linker
passes depending on system configuration then the Zephyr CMake linker
script generator has been updated to use pass names instead of pass
numbers.
This allows greater flexibility as a section can now be active based on
the settings on the pass and not the linking pass index number.
As part of this, the `PASS` processing in `linker_script_common.cmake`
has been adjusted so that it properly handles when a linking pass is
handling multiple settings, such as both `LINKER_APP_SMEM_UNALIGNED`
and `DEVICE_HANDLES_PASS1` in same linking pass.
As the number of linking passes are more flexible, then the PASS
argument in `zephyr_linker_section()` and
`zephyr_linker_section_configure()` has been updated to also support
a `NOT <name>` argument, for example: `PASS NOT LINKER_ZEPHYR_FINAL`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Currently all calls to `configure_linker_script()` specifies `-D<name>`
when calling `configure_linker_script()`.
This works well for the gcc pre-processed ld linker script templates,
but Zephyr also supports a CMake linker script generator which can be
used for ld scripts and armlink scatter files.
In this case, a `-D` must be stripped.
This commit changes this so that Zephyr CMake build system calls
`configure_linker_script()` without `-D`.
Thus the `LINKER_SCRIPT` choice can decide how this information should
be passed to underlying linker script functionality, that is `-D` for
linker script template and CMake variable for the CMake linker script
generator.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
When QEMU is running in icount mode, the behaviour regarding
the CPU being in sleep mode is configurable, with the default
value being set to 'off'. In this case, instruction counting
continues even when the CPU is sleeping or no target time is
set in the system timer. If the sleep parameter is set to
'on', instruction counting stops if the CPU is sleeping, and
the instruction count will fast-forward directly to the next
target time once it is being set.
In the Xilinx derivative of QEMU (which simulates ZynqMP and
Zynq-7000 SoCs), the default configuration causes QEMU to no
longer accept control commands via the console or remotely
whenever Zephyr enters and remains in idle mode.
Therefore, this commit makes the value of the sleep para-
meter of the icount functionality configurable, with the
default value remaining 'off'. The value can be changed at
board level alongside with the specification of the icount
shift value.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@Weidmueller.com>
This commit creates a new `zephyr_build_string()` function.
`zephyr_build_string()` provides a common way of constructing a build
string based on board name, board revision, and build type.
Having this as a function facilitate creation of names in a common way
and thus helps to ensure naming consistency, especially if newer info
is later embedded into the build string.
Initially the build string will be used to lookup configuration
fragments and devicetree overlay files.
This function is used by `zephyr_file(CONF_FILES ...)`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This option was deprecated for the v2.6 release, and has therefore met
the 2 release deprecation cycle requirements.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update -fno-pie to only be added when relevant. This fixes native_posix
builds on Debian hosts.
* Debian and other Linux distributions have ld with --warn-textrel as
default.
* The option generates a warning when linking on x86.
* The warning make scripts/twister fail because we treat all warnings
as error.
* The warning is issued when no PIE objects are linked against PIE
library.
* PIE (Position Independent Executable) or not can be seen with the
following command.
* When you want to generate non PIE, link with `-no-pie.`
Non PIE
$ readelf -l build/zephyr/zephyr.elf | grep 'Elf file type is'
Elf file type is EXEC (Executable file)
PIE
$ readelf -l /lib/x86_64-linux-gnu/libc.so.6 | \
grep 'Elf file type is'
Elf file type is DYN (Shared object file)
Issue #35244
Signed-off-by: Yuval Peress <peress@google.com>
Setting of DTC_OVERLAY_FILE as an environment setting was deprecated
before Zephyr 1.14 LTS.
This commit remove the support for this possibility and thus cleans up
the build system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #36558#32577
This commit introduces CMAKE_C_COMPILE_FEATURES and
CMAKE_CXX_COMPILE_FEATURES.
This allows users to use the `target_compile_features()` in their own
code.
In Zephyr, the CMAKE_C/CXX_COMPILE_FEATURES are defined based on the
compiler and the Kconfig / CSTD setting.
Doing so ensures that a user compiling Zephyr with c99 and specifies
`target_compile_features(<target> ... c_std_11)` will get an error.
And similar if building Zephyr with C++ support and c++11, but testing
for `target_compile_features(<target> ... cxx_std_17)`.
For example in the C++ case, the user must ensure that Zephyr is
compiled with C++17, that is: CPLUSPLUS=y and STD_CPP17=y, in which case
the CMAKE_CXX_COMPILE_FEATURES will contain support for C++17 and thus
the `target_compile_features(<target> ... cxx_std_17)` will succeed.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
In order to retrieve TOOLCHAIN_NAME from Kconfig,
generic.cmake points to any toolchain as a
boilerplate implementation. Now, target.cmake file handles
proper toolchain selection.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
The root cause of #38591 was region symbols being placed before the
section description for data region.
To support both schemes with the linker generator, a new
`SYMBOL SECTION` argument has been added to the zephyr_linker_group()
function.
This commit updates the arm/linker.cmake CMake linker file to use the
new `SYMBOL SECTION` argument for the data region group and text region
group so that those two groups now behave identical to the behavior when
using the cortex_m linker.ld template.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The root cause of #38591 was region symbols being placed before the
section description for data region.
Some region start symbols are placed before section description, other
region start symbols are placed inside the first section in the region
and thus identical to the sections own first symbol.
To support both schemes with the linker generator, a new
`SYMBOL SECTION` argument has been added to the zephyr_linker_group()
function.
The ld_script.cmake linker script generator has been updated to support
the new argument so that generated ld linker script has identical
behavior to the templated ld linker scripts.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit sets the minimum required Zephyr SDK version to 0.13.1,
which fixes the following critical issues:
1. Xtensa initial malloc failure (GitHub issue #38258)
2. ARMv8-M security extension vulnerability (CVE-2021-35465)
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Fixes: #38761
The introduction of zephyr_library_property in #38347 contained a
stray function call `target_compile_definitions()` resulting in the
library property name and value to also be added compile definitions to
the Zephyr library.
The Zephyr library property is an internal property and is not supposed
to be added as compile definitions, and thus this call is removed with
this commit.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
GDB can be built with or without Python support. When built with Python
support this can cause a particular problem: The gdb executable relies
on shared libraries that are bound to a specific Python version. But
since most Linux distributions typically ship with a single version, it
is very difficult to choose which one to target when building GDB.
When GDB executes, if it fails to load the shared libraries it will exit
immediately with an error code of 127 and output resembling this:
/home/carles/bin/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb:
error while loading shared libraries: libpython3.8.so.1.0: cannot open
shared object file: No such file or directory
There are two known approaches to shipping multiple gdb executables:
- The Zephyr SDK ships a default gdb with Python enabled, and then a
separate gdb-no-py executable with Python disabled
- GNU Arm Embedded ships with a default gdb with Python disabled, and an
additional gdb-py with Python enabled
To mitigate the problem of not being able to debug, fall back to a
'gdb-no-py' if it exists whenever the standard gdb executable fails to
even run.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Fixes: #38558
This commit removes: `cmake_policy(SET CMP0079 OLD)`
This means Zephyr will now allow the new CMP0079 behavior introduced
with CMake version 3.13.
Code has now been examined and no occurences has been found where the
INTERFACE keyword was used with `target_link_libraries()` outside the
CMakeLists.txt scope where the original libraries were created.
As an additional safeguard `./scripts/twister -c -N --cmake-only`
has been executed before and after this change and all `build.ninja`
files for each test / sample have been diffed.
Removing the CMP0079 policy creates identical build files, hence removal
of the old policy will not impact the build.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit adds the `nostdincxx` C++ compiler property for GCC, which
is specified when the C++ standard library (`CONFIG_LIB_CPLUSPLUS`) is
disabled.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds a new C++ compiler property `nostdincxx` which
specifies the C++ compiler flag for excluding the C++ standard library
include directory from the include paths.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Fixes: #37637
toolchain_parse_make_rule() parses depfiles and converted `\\` to the
CMake list separator `;`.
However, gcc -M might create depfiles with windows path separator `\`
causing this conversion to fail, as a path like:
c:\...\zephyr\samples\drivers\led_ws2812\nrf52-bindings.h
resulting in a file list as:
c:;...;zephyr;samples;drivers;led_ws2812;nrf52-bindings.h
which results in a CMake configure dependency to be added to `C:`.
As C: is always newer than the build.ninja file, this resulted in
continues CMake re-invocation.
As a small side-note, the `\` in file name did only occur in situations
where a relative past had been used elsewhere in the build system, such
as here:
https://github.com/zephyrproject-rtos/zephyr/blob/\
c3050a5aab1e86d02642eb4c6a027419e6a3a096/samples/drivers/led_ws2812/\
boards/nrf52dk_nrf52832.overlay#L9
To ensure proper handling of files, then all files are converted to
CMake paths, that is with forward slashes: `/`
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
If the BOARD_RUNNER_ARGS_${runner_id} variable contains anything, add
it to the global property of the same name with all the final runner
args from board_runner_args() and friends.
This allows use cases like this:
west build ... -- -DBOARD_RUNNER_ARGS_jlink="--some-jlink-arg"
The ${runner_id} part is the runner's name converted to a C
identifier, i.e. with special characters changed to underscores.
So e.g. the 'dfu-util' runner would use BOARD_RUNNER_ARGS_dfu_util.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Cadence XCC is based off of a very old 4.2 gcc compiler, which didn't
perfectly support C99 "inline" semantics with respect to
cross-translation-unit inline linkage (which Zephyr does not use, our
inlines are static only) and declaration order.
Fix the one spot where we were calling an inline before its
ALWAYS_INLINE definition, and add a flag to suppress the warning so
CI's trying to build with XCC and -Werror don't flip out.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This introduces a dedicated zephyr_library_property() function which
provides a common way to set Zephyr build system known properties on
Zephyr libraries.
As a first common property is the `ALLOW_EMPTY` property which allows
to create a `zephyr_library()` without putting any content inside of it.
In general libraries should not be created unless there are files to
places inside of it, however in some cases there are so many
`zephyr_library_sources_ifdef(<setting> <file.c>)`
where testing each setting before creating the library may not be
desired.
This commit allows the following construct in those cases:
```
zephyr_library()
zephyr_library_property(ALLOW_EMPTY TRUE)
zephyr_library_sources_ifdef(CONFIG_SETTING_1 file_1.c)
zephyr_library_sources_ifdef(CONFIG_SETTING_2 file_2.c)
...
zephyr_library_sources_ifdef(CONFIG_SETTING_n file_n.c)
```
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
It may be needed to run Zephyr at EL1NS level with `CONFIG_ARMV8_A_NS`
In order to run at EL1NS, you'll need a proper Firmware loaded in the
FVP model to run Zephyr at non-secure EL3.
The ARM TF-A for FVP can used to run Zephyr as preloaded BL33.
This adds the necessary cmake scripts to load the TF-A binaries and
load Zephyr as preloaded BL33 payload.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
The `set_conf_file()` was deprecated in
6d4ba3490f
which is before Zephyr v1.14 LTS.
Let's remove the support now, before releasing a new LTS.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
