Lines Matching +full:overflow +full:- +full:control
24 - Any configuration of memory regions which need to have special caching or
25 write-back policies for basic hardware and driver function. Note that most
30 ARMv7-M/ARMv8-M this is called the System Address Map, other CPUs may
34 - A read-only, executable region or regions for program text and ro-data, that
35 is accessible to user mode. This could be further sub-divided into a
36 read-only region for ro-data, and a read-only, executable region for text, but
38 threads running in user mode can read ro-data and fetch instructions.
40 - Depending on configuration, user-accessible read-write regions to support
45 text/ro-data, this is sufficient for the boot time configuration.
47 Hardware Stack Overflow
53 individual stack frames, use compiler-assisted :kconfig:option:`CONFIG_STACK_CANARIES`
57 health of the system after a supervisor mode stack overflow, and any instances
64 which is set to be read-only and is at either the beginning or immediately
69 mode; disabling this may free 1-2 MPU regions depending on the MPU design.
110 - :c:func:`k_stack_alloc_init` sets up a k_stack with its storage
116 - :c:func:`k_pipe_alloc_init` sets up a k_pipe object with its
122 - :c:func:`k_msgq_alloc_init` sets up a k_msgq object with its
128 - :c:func:`k_poll` when invoked from user mode, needs to make a kernel-side
132 - :c:func:`k_queue_alloc_prepend` and :c:func:`k_queue_alloc_append`
137 - :c:func:`k_object_alloc` allows for entire kernel objects to be
152 buffer, plus program text and read-only data. The memory domain APIs are the
158 to minimize the number of boot-time MPU regions.
160 Memory domains are *not* intended to control access to memory from supervisor
162 not allow for the definition of regions which are read-only to user mode but
163 read-write to supervisor mode. A great deal of care must be taken when working
165 accessing such a region. Any attempt to use memory domain APIs to control
167 policy is only intended to be controlled by boot-time memory regions.
169 Memory domain APIs are only available to supervisor mode. The only control
185 control access to system memory. Defining memory partitions are subject
188 - The partition must represent a memory region that can be programmed by
190 underlying hardware constraints. For example, many MPU-based systems require
192 size. For MMU-based systems, the partition must be aligned to a page and
195 - Partitions within the same memory domain may not overlap each other. There is
198 boot-time memory regions, however whether a memory domain partition can
199 overlap a boot-time memory region is architecture specific.
201 - The same partition may be specified in multiple memory domains. For example
204 - Care must be taken in determining what memory to expose in a partition.
208 - Memory domain partitions are intended to control access to system RAM.
210 may not be supported by the architecture; this is true for MMU-based systems.
216 ------------------------
219 a read-write partition for it which may be added to a domain:
221 .. code-block:: c
232 ---------------------------
247 Automatic memory partitions are only configured as read-write
253 .. code-block:: c
257 /* Declare a k_mem_partition "my_partition" that is read-write to
280 .. code-block:: c
287 The build-time logic for setting up automatic memory partitions is in
290 memory partition with the ``--library`` argument.
294 top-level ``CMakeLists.txt`` adds the following:
296 .. code-block:: none
298 gen_app_partitions.py ... --library libc.a z_libc_partition ..
300 For pre-compiled libraries there is no support for expressing this in the
301 project-level configuration or build files; the toplevel ``CMakeLists.txt`` must
310 Pre-defined Memory Partitions
311 -----------------------------
313 There are a few memory partitions which are pre-defined by the system:
315 - ``z_malloc_partition`` - This partition contains the system-wide pool of
321 - ``z_libc_partition`` - Contains globals required by the C library and runtime.
325 Library-specific partitions are listed in ``include/app_memory/partitions.h``.
333 ----------------------
341 .. code-block:: c
348 ------------------------------------------
355 .. code-block:: c
377 .. code-block:: c
397 ------------------------
403 .. code-block:: c
414 ----------------------------------------------
419 .. code-block:: c
428 ------------------------------
431 to the partition. Since the access control of memory partitions relies on
436 is found in the architecture-specific include file
440 .. code-block:: c
444 /* Denote partition is privileged read/write, unprivileged read-only */