devicetree: Add 'zephyr,memory-attr' and DT helpers
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>
2023-07-05 21:10:32 +08:00
|
|
|
# Copyright (c) 2023, Carlo Caione <ccaione@baylibre.com>
|
|
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
|
|
|
|
|
include: [base.yaml]
|
|
|
|
|
|
|
|
|
|
properties:
|
dts: bindings: Move zephyr,memory-region property definition
Move it to a common file named `zephyr,memory-common.yaml`, which
replaces `zephyr,memory-attr.yaml` and takes its contents as well.
This is so that another binding, e.g., `vnd,memory-region`, can support
being combined with the `zephyr,memory-region` binding like so:
node@deadbeef {
compatible = "vnd,memory-region", "zephyr,memory-region";
zephyr,memory-region = "NAME";
...
};
To allow this, edtlib would require `vnd,memory-region` to include the
property definitions from this new common file.
The same can't be done by including `zephyr,memory-region.yaml` directly
because that file marks the property in question as always required, and
it shouldn't be required whenever the `vnd,memory-region` compatible is
used on its own.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2024-05-03 15:20:27 +08:00
|
|
|
zephyr,memory-region:
|
|
|
|
|
type: string
|
|
|
|
|
description: |
|
|
|
|
|
Signify that this node should result in a dedicated linker script
|
|
|
|
|
memory region in the final executable. The region address and size
|
|
|
|
|
is taken from the <reg> property, while the name is the value of
|
|
|
|
|
this property.
|
|
|
|
|
|
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-08-16 18:48:26 +08:00
|
|
|
zephyr,memory-region-mpu:
|
devicetree: Add 'zephyr,memory-attr' and DT helpers
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>
2023-07-05 21:10:32 +08:00
|
|
|
type: string
|
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-08-16 18:48:26 +08:00
|
|
|
deprecated: true
|
|
|
|
|
description: |
|
|
|
|
|
Signify that this node should result in a dedicated MPU region.
|
|
|
|
|
Deprecated in favor of 'zephyr,memory-attr'.
|
|
|
|
|
|
|
|
|
|
zephyr,memory-attr:
|
|
|
|
|
type: int
|
devicetree: Add 'zephyr,memory-attr' and DT helpers
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>
2023-07-05 21:10:32 +08:00
|
|
|
description: |
|
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-08-16 18:48:26 +08:00
|
|
|
Attribute or set of attributes (bitmask) for the memory region. See
|
|
|
|
|
'include/zephyr/dt-bindings/memory-attr/memory-attr.h' for a
|
|
|
|
|
comprehensive list with description of possible values.
|
devicetree: Add 'zephyr,memory-attr' and DT helpers
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>
2023-07-05 21:10:32 +08:00
|
|
|
|
|
|
|
|
reg:
|
|
|
|
|
required: true
|