|
| 1 | +.. _mpu_stack_objects: |
| 2 | + |
| 3 | +MPU Stack Objects |
| 4 | +################# |
| 5 | + |
| 6 | +Thread Stack Creation |
| 7 | +********************* |
| 8 | + |
| 9 | +Thread stacks are declared statically with :c:macro:`K_THREAD_STACK_DEFINE()` |
| 10 | +or embedded within structures using c:macro:`K_THREAD_STACK_MEMBER()` |
| 11 | + |
| 12 | +For architectures which utilize memory protection unit (MPU) hardware, |
| 13 | +stacks are physically contiguous allocations. This contiguous allocation |
| 14 | +has implications for the placement of stacks in memory, as well as the |
| 15 | +implementation of other features such as stack protection and userspace. The |
| 16 | +implications for placement are directly attributed to the alignment |
| 17 | +requirements for MPU regions. This is discussed in the memory placement |
| 18 | +section below. |
| 19 | + |
| 20 | +Stack Guards |
| 21 | +************ |
| 22 | + |
| 23 | +Stack protection mechanisms require hardware support that can restrict access |
| 24 | +to memory. Memory protection units can provide this kind of support. |
| 25 | +The MPU provides a fixed number of regions. Each region contains information |
| 26 | +about the start, end, size, and access attributes to be enforced on that |
| 27 | +particular region. |
| 28 | + |
| 29 | +Stack guards are implemented by using a single MPU region and setting the |
| 30 | +attributes for that region to not allow write access. If invalid accesses |
| 31 | +occur, a fault ensues. The stack guard is defined at the bottom (the lowest |
| 32 | +address) of the stack. |
| 33 | + |
| 34 | +Memory Placement |
| 35 | +**************** |
| 36 | + |
| 37 | +During stack creation, a set of constraints are enforced on the allocation of |
| 38 | +memory. These constraints include determining the alignment of the stack and |
| 39 | +the correct sizing of the stack. During linking of the binary, these |
| 40 | +constraints are used to place the stacks properly. |
| 41 | + |
| 42 | +The main source of the memory constraints is the MPU design for the SoC. The |
| 43 | +MPU design may require specific constraints on the region definition. These |
| 44 | +can include alignment of beginning and end addresses, sizes of allocations, |
| 45 | +or even interactions between overlapping regions. |
| 46 | + |
| 47 | +Some MPUs require that each region be aligned to a power of two. These SoCs |
| 48 | +will have :option:`CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT` defined. |
| 49 | +This means that a 1500 byte stack should be aligned to a 2kB boundary and the |
| 50 | +stack size should also be adjusted to 2kB to ensure that nothing else is |
| 51 | +placed in the remainder of the region. SoCs which include the unmodified ARM |
| 52 | +v7m MPU will have these constraints. |
| 53 | + |
| 54 | +Some ARM MPUs use start and end addresses to define MPU regions and both the |
| 55 | +start and end addresses require 32 byte alignment. An example of this kind of |
| 56 | +MPU is found in the NXP FRDM K64F. |
| 57 | + |
| 58 | +MPUs may have a region priority mechanisms that use the highest priority region |
| 59 | +that covers the memory access to determine the enforcement policy. Others may |
| 60 | +logically OR regions to determine enforcement policy. |
| 61 | + |
| 62 | +Size and alignment constraints may result in stack allocations being larger |
| 63 | +than the requested size. Region priority mechanisms may result in |
| 64 | +some added complexity when implementing stack guards. |
| 65 | + |
0 commit comments