Lines Matching +full:memory +full:- +full:to +full:- +full:memory
3 Memory Attributes
6 It is possible in the devicetree to mark the memory regions with attributes by
7 using the ``zephyr,memory-attr`` property. This property and the related memory
8 region can then be retrieved at run-time by leveraging a provided helper
12 and explained in :zephyr_file:`include/zephyr/dt-bindings/memory-attr/memory-attr.h`.
14 For example, to mark a memory region in the devicetree as non-volatile, cacheable,
15 out-of-order:
17 .. code-block:: devicetree
19 mem: memory@10000000 {
20 compatible = "mmio-sram";
22 zephyr,memory-attr = <( DT_MEM_NON_VOLATILE | DT_MEM_CACHEABLE | DT_MEM_OOO )>;
27 The ``zephyr,memory-attr`` usage does not result in any memory region
28 actually created. When it is needed to create an actual section out of the
29 devicetree defined memory region, it is possible to use the compatible
30 :dtcompatible:`zephyr,memory-region` that will result (only when supported
33 The ``zephyr,memory-attr`` property can also be used to set
34 architecture-specific and software-specific custom attributes that can be
35 interpreted at run time. This is leveraged, among other things, to create MPU
36 regions out of devicetree defined memory regions, for example:
38 .. code-block:: devicetree
40 mem: memory@10000000 {
41 compatible = "mmio-sram";
43 zephyr,memory-region = "NOCACHE_REGION";
44 zephyr,memory-attr = <( DT_MEM_ARM(ATTR_MPU_RAM_NOCACHE) )>;
47 See :zephyr_file:`include/zephyr/dt-bindings/memory-attr/memory-attr-arm.h` and
52 The conventional and recommended way to deal and manage with memory regions
53 marked with attributes is by using the provided ``mem-attr`` helper library by
55 list of memory regions and their attributes are compiled in a user-accessible
56 array and a set of functions is made available that can be used to query, probe
61 The ``zephyr,memory-attr`` property is only a descriptive property of the
62 capabilities of the associated memory region, but it does not result in any
63 actual setting for the memory to be set. The user, code or subsystem willing
64 to use this information to do some work (for example creating an MPU region
65 out of the property) must use either the provided ``mem-attr`` library or
66 the usual devicetree helpers to perform the required work / setting. Note,
68 uses this information to properly initialize caching at boot. See
71 A test for the ``mem-attr`` library and its usage is provided in
74 Migration guide from ``zephyr,memory-region-mpu``
77 When the ``zephyr,memory-attr`` property was introduced, the
78 ``zephyr,memory-region-mpu`` property was removed and deprecated.
80 The developers that are still using the deprecated property can move to the new
81 one by renaming the property and changing its value according to the following list:
83 .. code-block:: none
85 "RAM" -> <( DT_ARM_MPU(ATTR_MPU_RAM) )>
86 "RAM_NOCACHE" -> <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>
87 "FLASH" -> <( DT_ARM_MPU(ATTR_MPU_FLASH) )>
88 "PPB" -> <( DT_ARM_MPU(ATTR_MPU_PPB) )>
89 "IO" -> <( DT_ARM_MPU(ATTR_MPU_IO) )>
90 "EXTMEM" -> <( DT_ARM_MPU(ATTR_MPU_EXTMEM) )>
92 Memory Attributes Heap Allocator
95 It is possible to leverage the memory attribute property ``zephyr,memory-attr``
96 to define and create a set of memory heaps from which the user can allocate
97 memory from with certain attributes / capabilities.
100 with one of the memory attributes listed in
101 :zephyr_file:`include/zephyr/dt-bindings/memory-attr/memory-attr-sw.h` is added
102 to a pool of memory heaps used for dynamic allocation of memory buffers with
107 .. code-block:: none
113 For example we can define several memory regions with different attributes and
114 use the appropriate attribute to indicate that it is possible to dynamically
115 allocate memory from those regions:
117 .. code-block:: devicetree
119 mem_cacheable: memory@10000000 {
120 compatible = "mmio-sram";
122 zephyr,memory-attr = <( DT_MEM_CACHEABLE | DT_MEM_SW_ALLOC_CACHE )>;
125 mem_non_cacheable: memory@20000000 {
126 compatible = "mmio-sram";
128 zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE | ATTR_SW_ALLOC_NON_CACHE )>;
131 mem_cacheable_big: memory@30000000 {
132 compatible = "mmio-sram";
134 zephyr,memory-attr = <( DT_MEM_CACHEABLE | DT_MEM_OOO | DT_MEM_SW_ALLOC_CACHE )>;
137 mem_cacheable_dma: memory@40000000 {
138 compatible = "mmio-sram";
140 zephyr,memory-attr = <( DT_MEM_CACHEABLE | DT_MEM_DMA |
144 The user can then dynamically carve memory out of those regions using the
145 provided functions, the library will take care of allocating memory from the
148 .. code-block:: c
153 // Allocate 0x100 bytes of cacheable memory from `mem_cacheable`
156 // Allocate 0x200 bytes of non-cacheable memory aligned to 32 bytes
160 // Allocate 0x100 bytes of cacheable and dma-able memory from `mem_cacheable_dma`
163 When several regions are marked with the same attributes, the memory is allocated:
165 1. From the regions where the ``zephyr,memory-attr`` property has the requested
171 3. If there is not enough space, from the next bigger region able to
176 .. code-block:: c
178 // This memory is allocated from `mem_non_cacheable`
181 // This memory is allocated from `mem_cacheable_big`
186 The framework is assuming that the memory regions used to create the heaps
188 initializing and setting the memory area before calling
193 example by leveraging the ``zephyr,memory-region`` property to create a
194 proper linker section to accommodate the heap.