Removes mention of child image to prevent confusion with other
systems that have no relation to sysbuild
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Adds details to the application development page and sysbuild
page documenting the variable, how it works and how it should
be used
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
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 commit export TWEAK version to code through version.h.
This aligns the symbols available in code with those available in
CMake and Kconfig.
The new define is available for both KERNEL, APP, and custom version
types (such as MCUBOOT).
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Currently it is tedious to know the level of an interrupt for
a node in C. One would have to go through a very complex and
error prone macros to check if there's a parent interrupt
controller & if the controller has an interrupt number and thus
not a pseudo interrupt controller like the one found in
`rv32m1`. The level of a node is required to encode the
Zephyr's multi-level interrupt number
Since it is easier to do it in the `gen_defines` script, let's
do the heavy lifting there so that we can introduce new DT
macros to get the interrupt level very easily later.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Extend the gen_defines.py write_interrupts(node) function to
generate macros to get the interrupt controller for an
interrupt specifier by idx and by name.
The information is already generated by edtlib.py and stored in
node.interrupts[].controller. This addition uses the node pointed
to by the controller member to generate the following example output
define DT_N_S_device1_IRQ_IDX_0_CONTROLLER \
DT_N_S_gpio_800
define DT_N_S_device1_IRQ_NAME_test4_CONTROLLER \
N_S_device1_IRQ_IDX_0_CONTROLLER
Signed-off-by: Bjarki Arge Andreasen <bjarki@arge-andreasen.me>
Another round of repeated words cleanup. This commit tries to keep the
diff minimal and line wrapping was mostly left intact in the touched
files, as having them consistent across the documentation is probably
the topic of a future tree-wide cleanup (or not)
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Update the inter-node dependencies documentation to clarify the child
node dependency inheritance recently introduced in 403640b75e.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Convert the warning about multiple symbol definitions to a dedicated
section. This allows the warning to be restricted to the information
that is non-intuitive, with a note for actions that should be taken
when working with multiple definitions.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Make sure devicetree code blocks all have proper pygments language set.
Fixed a few other "none" code blocks as well.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Add proper pygments settings to make Kconfig snippets look pretty.
Also fixed a few config and devicetree code blocks.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
- Updated basic samples READMEs to use the new zephyr:code-sample::
directive. Dropped "-sample" suffix that's not required anymore now
that samples have their own namespace.
- Updated all references to the samples to use the :zephyr:code-sample:
role. Checked and updated the wording of said references to account
for the fact that samples should not have "... sample" in their name
anymore.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
The configuration option was deprecated and removed as the default in
MCUBoot commit 9315654d7951fb2c269251db94e04cd062d0b89a.
Signed-off-by: Xudong Zheng <7pkvm5aw@slicealias.com>
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>
Add a brief subsection about how to build a Zephyr application without
flashing it.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
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>
The 'zephyr,memory-region-mpu' property was addede gqas a
convenient way to create and configure MPU regions using information
coming from DT. It has been used a lot since it was introduced so I
guess we can consider it a Zephyr success story ™ .
Unfortunately it has been proved to be a bit limited and with some
important limitations:
1. It was introduced as a property of the compatible
zephyr,memory-region that is used to create linker regions and
sections from DT data. This means that we can actually create MPU
regions only for DT-defined regions and sections.
2. The naming is unfortunate because it is implying that it is used only
for MPU.
3. It is misplaced being in include/zephyr/linker/devicetree_regions.h
and still it has nothing to do with the linker at all.
4. It is exporting a function called LINKER_DT_REGION_MPU that again has
nothing to do with the linker.
Point (1) is also particularly limiting because it is preventing us to
characterize memory regions that are not generated using the
'zephyr,memory-region' compatible, like generic mmio-sram regions.
While we fix all the issues, we also want to extend a bit the range of
usefulness of this property. We are renaming it 'zephyr,memory-attr' and
it is now carrying information about the type of memory the property is
attached to (cacheable, non-cacheable, IO, eXecutable, etc...). The user
can use this property and the DT API coming with it to act on the memory
node it is accompanied by.
We are still providing the DT_MEMORY_ATTR_APPLY() macro that can be used
to create the MPU regions as before, but we are adding also a
DT_MEMORY_ATTR_FOREACH_NODE() macro that can be used to cycle through
the memory nodes and act on those.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Rename the gen_handles script and all of its references/associated files
to gen_device_deps. The new new makes things more clear, because the
script just take care of generating, for each device, an array of device
dependencies. While device handles are used internally to store this
information, it is in reality an implementation detail.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit clarifies the snippet processing order when multiple
snippets are specified.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
Add a reference to the check_init_priorities script in the cmake
"Supporting Scripts and Tools" section.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This commit adds change snippets to use the new EXTRA_DTC_OVERLAY_FILE
and EXTRA_CONF_FILE Zephyr build system variables instead of
DTC_OVERLAY_FILE and OVERLAY_CONFIG.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Introduce EXTRA_CONF_FILE and EXTRA_DTC_OVERLAY_FILE and remove old
references to OVERLAY_CONFIG.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
When debugging devicetree related issues, it may be useful to turn macro
expansion tracking off. Let's document this in the troubleshooting
section.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This is an FAQ and we don't have a satisfactory page that describes
the current state of the world for how to troubleshoot. This leads
to frustrated users and duplicated support efforts. Try to improve
this by at least writing down what people have to do today.
If we ever improve the situation by adding a machine-readable map
between drivers, Kconfig options, and DT compatibles, we can hopefully
do better than this, but at least it's a start.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes misspelling of `scans` in the description of `CONFIG_GEN_ISR_TABLES`
in the build system documentation.
Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>
Adds "fragment" to the Kconfig text, this is because these files
are known as Kconfig fragments, and when searching the
documentation for this, all you get are irrelevant results instead
of this page - which is by far the most important one.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Update the save-temps instruction to mention the new kconfig option
instead of setting EXTRA_CFLAGS directly.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Document this new build system feature.
Since its purpose is customizing application builds, the logical place
for the main body of documentation is in a new snippets/ directory in
doc/build/. Create that directory and add its initial documentation.
Like boards and samples, however, we expect people to write
documentation for each snippet within the directory that defines the
snippet itself. Therefore, add a new top-level snippets/ directory and
stub out the documentation needed to document individual snippets as
well.
Add documentation and cross-references in other required places as
well.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Benjamin Cabé