Lines Matching +full:extra +full:- +full:user +full:- +full:files
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
29 to maximize the number of available MPU regions for the end user. On
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
41 extra features like GCOV, HEP, etc.
44 memory it needs, and regions are defined which grant user mode access to
45 text/ro-data, this is sufficient for the boot time configuration.
53 individual stack frames, use compiler-assisted :kconfig:option:`CONFIG_STACK_CANARIES`
64 which is set to be read-only and is at either the beginning or immediately
68 This feature is optional and is not required to catch stack overflows in user
69 mode; disabling this may free 1-2 MPU regions depending on the MPU design.
72 and no extra MPU regions will be required.
77 Any thread running in user mode will need access to its own stack buffer.
78 On context switch into a user mode thread, a dedicated MPU region or MMU
84 Note that user threads have access to the stacks of other user threads in
87 so each user thread only has access to its own stack if such architecture
94 disabled. Regardless of these kconfigs, user threads cannot access
95 the stacks of other user threads outside of their memory domains.
102 directly by user mode. In order to use these system calls, invoking threads
110 - :c:func:`k_stack_alloc_init` sets up a k_stack with its storage
112 user. An alternative is to declare k_stacks that are automatically
116 - :c:func:`k_pipe_alloc_init` sets up a k_pipe object with its
118 by the user. An alternative is to declare k_pipes that are automatically
122 - :c:func:`k_msgq_alloc_init` sets up a k_msgq object with its
124 by the user. An alternative is to declare a k_msgq that is automatically
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`
135 memory provided by the user.
137 - :c:func:`k_object_alloc` allows for entire kernel objects to be
151 The kernel ensures that any user thread will have access to its own stack
152 buffer, plus program text and read-only data. The memory domain APIs are the
153 way to grant access to additional blocks of memory to a user thread.
158 to minimize the number of boot-time MPU regions.
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
167 policy is only intended to be controlled by boot-time memory regions.
170 user mode has over memory domains is that any user thread's child threads
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.
205 It is not appropriate to provide direct user mode access to any memory
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
229 objects spread out across several C files into a single partition.
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
258 * user mode. Note that we do not specify a base address or size.
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``.
326 For example, to use the MBEDTLS library from user mode, the
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 ------------------------------
436 is found in the architecture-specific include file
440 .. code-block:: c
444 /* Denote partition is privileged read/write, unprivileged read-only */