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>
This commit follows the parent commit work.
This commit introduces the following major changes.
1. Move all directories and files in 'include/zephyr/arch/arm/aarch32'
to the 'include/zephyr/arch/arm' directory.
2. Change the path string which is influenced by the changement 1.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
Move arm_mpu_mem_cfg header to common include directory.
The benefits are two-fold:
- Allow for out of tree SoC definitions to use them to
define mpu_regions.
- Remove odd relative include path
Signed-off-by: Moritz Fischer <moritzf@google.com>
In order to bring consistency in-tree, migrate all soc code to the
new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add MPU REGION_FLASH_SIZE definitions for 128M-512M flash sizes, to handle
arm SOCs with large flash regions.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Currently the only way for a BOARD/SOC to configure at compile time the
MPU regions is to add, in a soc-specific file, the 'mpu_config' struct
adding static entries for the new regions with the needed attributes
(cacheable, non-cacheable, etc...). This exported struct is then read by
the MPU driver at boot time and used to properly setup the MPU regions.
At the same time it is now possible to introduce new memory regions in
the DT using the newly introduced 'zephyr,memory-region' attribute.
What is missing is the link between these two solutions: that is how to
declare the memory regions in the DT and automatically configure these
regions in the MPU with the correct attributes.
This patch is trying to address exactly this problem.
It is now possible to declare the memory regions in the DT and define
the MPU attributes for the regions using the 'zephyr,memory-region-mpu'
property. When this new property is present together with the
'zephyr,memory-region' property and a the 'zephyr,memory-region'
compatible, the 'mpu_config' struct is automatically extended at
compile-time to host the DT defined regions with the correct MPU
attributes.
So for example in the DT we can now have:
sram_cache: memory@20200000 {
compatible = "zephyr,memory-region", "mmio-sram";
reg = <0x20200000 0x100000>;
zephyr,memory-region = "SRAM_CACHE";
zephyr,memory-region-mpu = "RAM";
};
and a new region will be created called "SRAM_CACHE" and a new MPU
region will be configure at boot time with the attribute
"REGION_RAM_ATTR".
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Added support for 8 MB MPU regions for SRAM sizes between 4 and 8 MB,
and 16 MB MPU regions for SRAM sizes between 8 and 16 MB.
Signed-off-by: Johan Öhman <johan.ohman@softube.com>
1. Added RT10xx and RT11xx configs
2. Added a new soc file for rt117x. There are clock differences
between the RT10xx and RT11xx series, hence the soc files
have been separated.
Signed-off-by: Ryan QIAN <jianghao.qian@nxp.com>
Before introducing the code for ARM64 (AArch64) we need to relocate the
current ARM code to a new AArch32 sub-directory. For now we can assume
that no code is shared between ARM and ARM64.
There are no functional changes. The code is moved to the new location
and the file paths are fixed to reflect this change.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
We move the configuration of the fixed MPU regions for ARM
Cortex-M SoCs in a common place under soc/arm/common/cortex-m,
instead of having this configuration present in each ARM SoC or
SoC Series definition. The rationale behind this is that for all
SoCs the fixed MPU regions configured at SoC definition are only
used for enforcing default Flash and SRAM access policies, and
currently, this is common to all ARM SoCs with MPU support.
We also simplify the Flash and SRAM MPU region definition,
aiming at using a single MPU region index to program each
of them.
We still support the possibility for ARM SoCs to opt-out and,
instead, define their own custom fixed MPU regions at SoC
definition. We do it using a Kconfig option, introduced
explicitly for this purpose.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
