Deprecating boards comes with similar challenges as with board aliases,
since BOARD_DEPRECATED is also set after parsing BOARD as user input.
With this patch, a deprecated board can be properly translated to a
board with identifiers. This opens up the possibility of recording all
legacy board names in `boards/deprecated.cmake`, such as:
set(mps2_an521_remote_DEPRECATED mps2/an521/cpu1)
Unlike with aliases, though, there are additional restrictions for
building with BOARD=<deprecated>, which only makes this feature suitable
for deprecating v1 boards:
* BOARD=<deprecated>/<identifier> is never allowed.
* BOARD=<deprecated>@<revision> is not allowed if the old board already
corresponds to a new board revision:
set(<deprecated>_DEPRECATED <new-board>@<new-revision>)
Future enhancements will be needed for deprecating v2 boards.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
To address concerns about lengthy board identifiers in HWMv2, the
proposal is to apply the existing BOARD_ALIAS feature, like so:
set(<alias>_BOARD_ALIAS <board>/<soc>)
It should then be possible to build with either:
-DBOARD=<alias> # expands to <board>/<soc>
-DBOARD=<alias>/<variant> # expands to <board>/<soc>/<variant>
However, this wouldn't work out of the box. A board alias can only be
expanded to a board name, without revision or identifier, because the
alias substitution happens after having parsed BOARD as user input -
namely, into BOARD (name), BOARD_REVISION, and BOARD_IDENTIFIER.
Furthermore, this means that in the legacy model, it was possible to
build with `-DBOARD=<alias>@<revision>`, and it would resolve to the
actual board name + revision.
To support both the old and new use cases, we can parse the alias just
like BOARD itself, then concatenate their identifiers as shown above.
Adding a revision works as before, but now it is also possible for the
alias to set its own revision. In this example:
set(<alias>_BOARD_ALIAS <board>@<rev-A>/<soc>/<variant>)
`<rev-A>` is treated as the default revision, and it can be overridden:
-DBOARD=<alias> # expands to <board>@<rev-A>/<soc>/<variant>
-DBOARD=<alias>@<rev-B> # expands to <board>@<rev-B>/<soc>/<variant>
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This commit improves board handling for boards in HWMv2.
On a CMake rerun, then BOARD_DIR is passed to `list_boards.py` which
is extended to take such parameter.
This allows to run `list_boards.py` whenever CMake reruns without the
penalty of searching for all board.yml files, as only the board.yml of
the current BOARD_DIR is processed.
This allows `list_boards.py` to be invoked and from there obtain list
of valid revisions and board identifiers for further board validation.
This removes the need for caching additional CMake variables related to
the board identifier and revision and thereby remove the risk of
settings becoming out of sync as only the board provided by user is
needed.
This work further ensure that use-cases described in #50536 is still
supported.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Legacy hw model picked the arch based on folder names.
The new hw model allows for greater flexibility and instead uses the
architecture defined by `CONFIG_ARCH` in Kconfig.
Therefore check that ARCH is defined and fail with a better error
message if ARCH is not defined. The error message includes the board and
SoC selected to make it easier to trace such errors.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
With hwmv2, the ARCH variable is not yet defined
when this module is loaded (kconfig is parsed after this).
So we cannot rely on it to detect if we are building for a
host target.
For this case, let's instead detect it by the BOARD or
BOARD_DIR which are some of the very few things defined
at this point.
We retain the old check to support hwmv1 boards which
may be in other folders.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
In quite a few places in the cmake files
${SOC_DIR}/${ARCH}/${SOC_PATH}
was used to get to something in the soc folder,
but these are only defined for soc_v1.
socv2 defines a full SOC_V2_DIR.
Let's define a common variable for the full path which
can be used in other cmake files,
and correct the current uses.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Fixes an issue in hwmv2 whereby an overlay file exists with the full
board name and identifier which worked in hwmv1
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Update board info printing to use the common term identifier.
Variant is used for the final part of the identifier when a board has
multiple build variants.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fixes: #68667
Kconfig is not fond of mixed path separators, therefore ensure CMake
style path is used in generated Kconfig files. CMake path style uses
`/`, and thus ensures correct behavior in Kconfig.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Create SOC_<soc>_DIR in addition to SOC_<SOC>_DIR variable.
Clear intermediate variables constructed by cmake_parse_arguments.
Set SOC_V2_DIR to point to the SoC dir of the actual SoC in use.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
To un-block continuing of soc and board porting then move all socs and
boards which have not yet been ported to boards_legacy / soc_legacy
folders.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Clear BOARD_CACHE when no or an invalid board identifier is provided
on first CMake invocation.
This allows users to re-run CMake and provide a valid board identifier
as well as avoiding `BOARD` to be replaced with an invalid BOARD_CACHED
value.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
In old hw model, board revisions was handled by creation of a
revisions.cmake file. In the new hw model, board revisions are defined
as integral part of board.yml, and revision.cmake is only needed and
used for custom revision format.
Users familiar with revision.cmake in old hw model may not be aware of
this difference, therefore provide warnings if developers create a
revision.cmake that is ignored by the build system.
Also fail a build if users specify a board revision for a board which
doesn't support revision. Such scenario can easily occur in the case
where a board developer may be creating a revisions.cmake file and
then try to build for a revision specified in that file.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The BOARD_IDENTIFIER is extracted from the BOARD argument provided by
the user.
Thereafter the BOARD_IDENTIFIER is compared to the list of valid board
identifiers returned by list_boards.py, and expanded with optional
fields as required.
Thereafter the expanded and full BOARD_IDENTIFIER is place as internal
variable in the CMake cache.
This means subsequent CMake invocations should use the expanded
BOARD_IDENTIFIER from the CMake cache instead of extracting it from the
BOARD variable.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Board is looked up without identifier string, which means a legacy
board may actually be found but later fails when board identifier is
included.
Thus test for HWMv1 and fail CMake is board identifier is provided for
board using HWMv1.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
A CMake rerun would not extract or determine the BOARD_IDENTIFIER
correctly because `list_boards.py` is only invoked for first CMake
invocation.
Therefore cache the BOARD_IDENTIFIER so that it's preserved between
CMake re-runs.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
With a single board now covering what used to be several boards, and
with the ability to omit SoC when building for a single SoC board, then
<board>_defconfig and <board>.dts lookup is improved.
A single SoC board may prefer to keep its defconfig entry point as
<board>_defconfig instead of <board>_<soc>_defconfig.
Also, a multi-SoC board / multi-core SoC board, which used to be
implemented as n-boards may wish to have common _defconfig settings in
a common <board>_defconfig file, and the SoC / cpuset specifics in
<board>_<soc>_defconfig / <board>_<soc>_<core>_defconfig.
Such defconfig support allows also to place build variant specifics in
its own <board>_<soc>_<variant>_defconfig file.
This commit allows multiple _defconfigs for a board and its identifiers.
Similar is implemented for a board's dts file.
If a <board>_<soc>_<core>.dts file is not found, the build system will
instead use <board>_<soc>.dts, and finally fallback to <board>.dts.
This allows a board to have a shared dts file for all board identifiers
which are identical while still support specific dts where required.
A dts file is a devicetree starting point and thus two dts files cannot
be used in together. For such cases, an ordinary board overlay file must
be used.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Allowing users to omit the SoC when building for a board containing a
single SoC make less typing required when building.
Full identifier is still supported.
This means that if board 'plank' contains a single SoC 'foo', then the
following input are equivalent:
-DBOARD=plank
-DBOARD=plank/foo
When building for variants on single SoC boards, a `//` can be used to
indicate SoC field and build system will insert the SoC if the board
has just a single SoC, as example build the 'bar' variant for 'plank'
board can be specified as:
-DBOARD=plank//bar
-DBOARD=plank/foo/bar
The enhancement allows all boards to specify the SoC on the board
without forcing users to type the SoC as part of BOARD input.
As example, -DBOARD=bbc_microbit, is allowed in addition to
-DBOARD=bbc_microbit/nrf52822.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Extend list_boards.py and update boards CMake module to handle HWMv2.
list_boards.py is extended to support board.yml file in each board
folder with various information related to the board, such as vendor,
soc, cpucluster, variants, revisions.
The HWMv2 removes the requirement for a _defconfig file.
It also unifies how board revisions, cpusets, etc is defined which again
provides an option for cleaner build system implementation for handling
of boards and their integration to the build system.
The CMake boards.cmake module is updated to take advantage of the
improved design.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Introduce dedicated arch and soc hw model v2 CMake module files.
Rename existing arch and soc cmake file to have a `_v1` post fix.
This help to identify the purpose of each of those files and thus a
cleaner implementation.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The list_hardware.py script parses archs.yml in all <arch-root>/arch
folders and soc.yml in all <soc-root>/soc sub-folders.
The archs.yml and soc.yml are introduced with hw model v2.
Hw model v2 removes the need for architecture knowledge of the SoCs,
and as part of this makes multi-arch and multi-core SoCs possible.
Hw model v2 also allows for greater flexibility in arch and SoC
organization as they can be organized freely.
As example SoCs can be organized by vendors, architecture, or any other
way as the socs.yml contains the path to the location of the SoC,
instead of relying on a specific arch.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Hw model v2 scheme offers SoC and maintainers the possibility to define
promptless SoCs settings which must be selected by the board Kconfig.
Having a board doing `select SOC_<name>` is a much cleaner approach then
selecting the SoC in a configuration file.
It furthermore removes the need to present all SoCs in choice groups, as
the SoC is now an internal setting to Kconfig.
This further has the benefit of not presenting users, especially
new-comers to Zephyr, with SoC selection options in menuconfig which
has potential to cause confusion.
It moves the SOC, SOC_SERIES, and SOC_FAMILY from arch/Kconfig into the
soc Kconfig tree, where they rightfully belongs.
With hw model v2, BOARD name is now passed from the build system to
Kconfig which ensures that the board name used in CMake is always in
sync with the board name used in Kconfig for hw model v2.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@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>
Grzegorz Swiderski