Lines Matching full:memory
3 Memory Protection Design
6 Zephyr's memory protection design is geared towards microcontrollers with MPU
7 (Memory Protection Unit) hardware. We do support some architectures, such as x86,
8 which have a paged MMU (Memory Management Unit), but in that case the MMU is
15 There are a few different levels on how memory access is configured when
16 Zephyr memory protection features are enabled, which we will describe here:
18 Boot Time Memory Configuration
24 - Any configuration of memory regions which need to have special caching or
26 MPUs have the concept of a default memory access policy map, which can be
27 enabled as a "background" mapping for any area of memory that doesn't
44 memory it needs, and regions are defined which grant user mode access to
80 A thread exceeding its stack buffer will start pushing data onto memory
81 it doesn't have access to and a memory access violation exception will be
85 the same memory domain. This is the minimum required for architectures to
86 support memory domains. Architecture can further restrict access to stacks
95 the stacks of other user threads outside of their memory domains.
100 A small subset of kernel APIs, invoked as system calls, require heap memory
101 allocations. This memory is used only by the kernel and is not accessible
104 object. Memory is drawn from a thread's resource pool using
135 memory provided by the user.
148 Memory Domains
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.
155 Conceptually, a memory domain is a collection of some number of memory
156 partitions. The maximum number of memory partitions in a domain
160 Memory domains are *not* intended to control access to memory from supervisor
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
170 user mode has over memory domains is that any user thread's child threads
173 All threads are members of a memory domain, including supervisor threads
174 (even though this has no implications on their memory access). There is a
176 they have not been specifically assigned to a domain, or inherited a memory
180 Memory Partitions
183 Each memory partition consists of a memory address, a size,
184 and access attributes. It is intended that memory partitions are used to
185 control access to system memory. Defining memory partitions are subject
188 - The partition must represent a memory region that can be programmed by
189 the underlying memory management hardware, and needs to conform to any
195 - Partitions within the same memory domain may not overlap each other. There is
196 no notion of precedence among partitions within a memory domain. Partitions
197 within a memory domain are assumed to have a higher precedence than any
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
202 there may be a shared memory area that multiple domains grant access to.
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.
209 Configuration of memory partitions which do not correspond to RAM
212 There are two ways to define memory partitions: either manually or
215 Manual Memory Partitions
231 Automatic Memory Partitions
234 Automatic memory partitions are created by the build system. All globals
237 contiguous block of memory, zero any BSS variables at boot, and define
238 a memory partition of appropriate base address and size which contains all
242 :alt: Automatic Memory Domain build flow
245 Automatic Memory Domain build flow
247 Automatic memory partitions are only configured as read-write
274 be properly aligned, and the total size of the region conforms to the memory
287 The build-time logic for setting up automatic memory partitions is in
290 memory partition with the ``--library`` argument.
305 the ``zephyr_library_app_memory`` function can be used to specify the memory
310 Pre-defined Memory Partitions
313 There are a few memory partitions which are pre-defined by the system:
316 memory used by libc malloc(). Due to possible starvation issues, it is
317 not recommended to draw heap memory from a global pool, instead
319 to specific memory domains.
329 Memory Domain Usage
332 Create a Memory Domain
335 A memory domain is defined using a variable of type
339 The following code defines and initializes an empty memory domain.
347 Add Memory Partitions into a Memory Domain
350 There are two ways to add memory partitions into a memory domain.
352 This first code sample shows how to add memory partitions while creating
353 a memory domain.
374 This second code sample shows how to add memory partitions into an initialized
375 memory domain one by one.
393 The maximum number of memory partitions is limited by the maximum
396 Memory Domain Assignment
399 Any thread may join a memory domain, and any memory domain may have multiple
400 threads assigned to it. Threads are assigned to memory domains with an API
410 In addition, if a thread is a member of a memory domain, and it creates a
413 Remove a Memory Partition from a Memory Domain
416 The following code shows how to remove a memory partition from a memory
423 The k_mem_domain_remove_partition() API finds the memory partition
425 memory domain.
431 to the partition. Since the access control of memory partitions relies on
459 The following memory domain APIs are provided by :zephyr_file:`include/zephyr/kernel.h`: