zephyr/doc
Carlo Caione e4a125b6a4 dt: Make zephyr,memory-attr a capabilities bitmask
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>
2023-09-15 12:46:54 +02:00
..
_doxygen drivers: mfd: npm1300: Initial version 2023-06-19 11:02:58 +02:00
_extensions/zephyr doc: Code samples must be referenced using new dedicated role 2023-09-13 09:15:34 +02:00
_scripts samples: net: cloud: drop Google Cloud IoT Core 2023-09-08 11:04:25 +02:00
_static doc: css: fix text color for toggle buttons in related samples 2023-09-13 09:15:34 +02:00
_templates
build dt: Make zephyr,memory-attr a capabilities bitmask 2023-09-15 12:46:54 +02:00
connectivity doc: Bluetooth: Mesh: Align wording for models instantiation req 2023-09-14 08:33:46 +02:00
contribute doc: Add instructions for installing Python dependencies 2023-09-06 15:16:38 +02:00
develop doc: picolibc: a few words about building without native support 2023-09-13 17:36:46 -04:00
hardware dt: Make zephyr,memory-attr a capabilities bitmask 2023-09-15 12:46:54 +02:00
images
introduction doc: introduction: Improve style and grammar across the chapter 2023-07-10 10:01:08 +00:00
kernel doc: interrupts: Document support for shared interrupts 2023-09-14 08:35:12 +02:00
project doc: release: drop the notes about listing github issues 2023-07-25 16:45:15 +02:00
releases dt: Make zephyr,memory-attr a capabilities bitmask 2023-09-15 12:46:54 +02:00
safety docs: safety: Add safety documentation 2023-06-22 06:01:39 -04:00
security doc: vulnerabilities: Add information about CVE-2023-4265 2023-08-16 15:05:35 +02:00
services dt: Make zephyr,memory-attr a capabilities bitmask 2023-09-15 12:46:54 +02:00
templates doc: Update sample.tmpl with new directive 2023-09-06 12:11:28 +02:00
404.rst
CMakeLists.txt doc: enable Sphinx tracebacks 2023-07-12 09:13:49 -04:00
conf.py doc: Make code-samples admonition collapsible 2023-09-06 12:11:28 +02:00
glossary.rst
index-tex.rst docs: safety: Add safety documentation 2023-06-22 06:01:39 -04:00
index.rst docs: safety: Add safety documentation 2023-06-22 06:01:39 -04:00
kconfig.rst
known-warnings.txt doc: Remove sphinx warning bt_ots_init pattern 2023-07-12 11:48:42 +02:00
LICENSING.rst doc licensing: Remove get_maintainers.pl 2023-06-25 02:46:42 -04:00
Makefile doc: align pseudo-Makefile with latest CMake changes 2023-07-13 14:27:56 +02:00
requirements.txt doc: Make code-samples admonition collapsible 2023-09-06 12:11:28 +02:00
substitutions.txt
zephyr.doxyfile.in doc: doxygen: Enable Doxygen autobrief 2023-07-13 09:20:51 +02:00