What is the change?
- Use a macro that search for "zephyr, memory-attr" in only
those nodes that have the property "zephyr, memory-regions".
- Fixes#83448.
Why is this needed?
- Using `DT_REG_ADDR` inside `DT_FOREACH_STATUS_OKAY_NODE_VARGS` can
lead to compiler warnings if a devicetree node has an addresses
larger than 64bits. An example of such node is wm8904 i3c with 92
bit encoding addresses `audio_codec: wm8904@1a0000000000000000`.
We can avoid this warning since this is not applicable for nodes
that have the attribute "zephyr,memory-regions".
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
With our builds for Arm M7 we are selecting FPU_SHARING and
MPU_STACK_GUARD. For that setup, we have
ARM_MPU_REGION_MIN_ALIGN_AND_SIZE=64 and
MPU_STACK_GUARD_MIN_SIZE_FLOAT=128. So worst case scenario,
we are going to have stack that is 64-byte aligned and
128-byte guard at the bottom of the buffer.
Fixes: #83714
Signed-off-by: Maciej Kusio <rysiof@gmail.com>
Previously, there were two separate Kconfig definitions
of ARM_MPU located at:
- arch/arm/core/mpu/Kconfig
- arch/arm64/core/cortex_r/Kconfig
This lead to incomplete default settings and unexpected
missing configurations.
This commit combines the two into a single unified definition
now located at arch/common/Kconfig to prevent this.
Signed-off-by: Samuel Chee <samche01@arm.com>
Following the binding rename to "nxp,sysmpu", update the Kconfig
option to align with the binding name and to better reflect the
option's purpose.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
When not using CONFIG_XIP (CONFIG_XIP=n)
the FLASH_0 mpu region needs to be removed,
otherwise it will have the default base
address = 0, which means that MPU will try
to configure the region with address 0.
We don't want this as in some situations
address 0 can be a restricted memory region
such as ROM code.
Signed-off-by: Alexandru Lastur <alexandru.lastur@nxp.com>
What is changed?
Updated the condition thats prevents mpu config for null dereference.
Added a new check so that mpu is configured for null dereference if
devicetree contains a memory-region node with:
- node address starting at 0
- size covered by the node is more than the null dereference page
size (0x400) and
- contains a memory-attr
Why is the change needed?
The check relied on flash base address to align with 0 for
configuring the mpu for null dereference but, a device tree
could have a flash starting at an address other than 0 and
still need the mpu config for null dereference.
The new extra check provides a way to connfigure mpu for
null dereference even if flash base address is not 0.
Note, though this change helps with mpu config for new boards having
flash address other than 0, this change does not change existing
behaviour for existing boards.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
Add initial support for the Cortex-M85 Core which is an implementation
of the Armv8.1-M mainline architecture.
The support is based on the Cortex-M55 support that already exists in
Zephyr.
Signed-off-by: Duy Nguyen <duy.nguyen.xa@renesas.com>
Memory region defined in devicetree can have attributes
that are not intended to be parsed by MPU library,
but might be valid for other components.
Signed-off-by: Nikodem Kastelik <nikodem.kastelik@nordicsemi.no>
ARM MPU implementation supports isolating thread stacks
within the same memory domain, and also is the only
supported operating mode. So select the corresponding
kconfig by default.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Disabling the MPU doesn't clear regions configuration. There is a risk
in multi-image environment that there are some old region setting e.g.
stack guard. This may cause a memory fault, because of different images
layout e.g. RO/RW.
Just clear and disable all regions configuration before the new
initialization.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
We follow the path of the header to define the guard, aarch32 was
removed some time ago and the guards still had AARCH32 in them, just
remove it and keep the guard consistent and short.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
NXP SYSMPU is used in other SoCs besides the Kinetis series. For
devices like S32K1xx, its bus interface clock lacks of clock gating
and it's driven by the system clock. Hence, only enable the module
clock for the Kinetis series.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Locate common mpu code together with other arm / nxp mpu code in the
arch folder where it logically belongs.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Let's make this official: we use the suffix `_MASK` for the define
carrying the GENMASK for the attributes, and the suffix `_GET(x)` for
the actual macro extracting the attributes.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
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>
It doesn't make sense to keep the aarch32 directory in the
'arch/arm/core' directory as the aarch64 has been moved out.
This commit introduces the following major changes.
1. Move all directories and files in 'arch/arm/core/aarch32' to
'arch/arm/core' and remove the 'arch/arm/core/aarch32' directory.
2. Move all directories and files in 'arch/include/aarch32' to
'arch/include' and remove the 'arch/include/aarch32' directory.
3. Remove the nested including in the 'arch/include/kernel_arch_func.h'
and 'arch/include/offsets_short_arch.h' header files.
4. Change the path string which is influenced by the changement 1
and 2.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
