Lines Matching +full:modified +full:- +full:timing +full:- +full:format
13 * ARMv7-M ISA with Thumb2 instruction set and ARM Embedded ABI (aeabi)
33 and architecture-dependent, and thread abortion possibly as well (required).
39 architecture-specific implementation for performance reasons (required).
44 * **Fault management**: for implementing architecture-specific debug help and
47 * **Linker scripts and toolchains**: architecture-specific details will most
50 * **Memory Management and Memory Mapping**: for architecture-specific details
53 * **Stack Objects**: for architecture-specific details on memory protection
71 * If running an :abbr:`XIP (eXecute-In-Place)` kernel, copy initialized data
79 Some examples of architecture-specific steps that have to be taken:
81 * If given control in real mode on x86_32, switch to 32-bit protected mode.
84 * Initialize a board-specific watchdog on Cortex-M3/4.
85 * Switch stacks from MSP to PSP on Cortex-M.
86 * Use a different approach than calling into _Swap() on Cortex-M to prevent
101 interrupt. For interrupts, that work is device-specific. For exceptions, it
129 It thus needs an architecture-specific implementation, called the
134 .. code-block:: C
143 the stub. This is commonly found in X86-based architectures.
171 is a fault, like divide-by-zero or invalid memory access, or an interrupt that
178 Multi-threading is the basic purpose to have a kernel at all. Zephyr supports
243 neither the ARM Cortex-M or ARCv2 port do this.
245 Since :code:`_Swap` is cooperative, the caller-saved registers from the ABI are
260 similar to locking the interrupts, but lighter-weight since interrupts can
262 non-preemptible.
279 If running a coop-only system, i.e. if :kconfig:option:`CONFIG_NUM_PREEMPT_PRIORITIES`
288 context switched out. This is to be implemented in an architecture-specific
298 The need for an architecture-specific thread termination implementation depends
302 One reason that has been encountered for having an architecture-specific
305 This is the case for ARM Cortex-M, where the CPU has to be taken out of handler
309 This means implementing an architecture-specific version of
357 On the other hand, the ARM Cortex-M has the :abbr:`NVIC (Nested Vectored
359 for an IDT-like table that is separate from the NVIC vector table. The position
361 programmable per-entry.
365 having a one-to-one mapping between exception and interrupt numbers (i.e.
368 IRQ-15).
377 Cortex-M has the SYSTICK exception. Finally, ARCv2 has the timer0/1 device.
387 port, since it is so useful for debugging. It is a simple polling, output-only,
399 instructions or in a lock-less manner in modern processors. Those are thus
410 around non-atomic operations exists. It is configured using the
413 * Find-least-significant-bit-set and find-most-significant-bit-set.
418 It is possible to use compiler built-ins to implement these, but be careful
434 * In a single-threaded system, in the only thread when the thread is not used
441 re-enable interrupts and invoke the power saving instruction. It can thus be
442 used in real application code, again in single-threaded systems.
460 out architecture-agnostic information and makes a policy
462 This function can be overridden to implement application-specific
472 Some architecture-specific definitions are needed in :zephyr_file:`include/zephyr/toolchain/gcc.h`.
483 If the target platform enables paging and requires drivers to memory-map
487 - :c:func:`arch_mem_map`
488 - :c:func:`arch_mem_unmap`
489 - :c:func:`arch_page_phys_get`
502 - "kernel" stacks defined with :c:macro:`K_KERNEL_STACK_DEFINE()` and related
508 - "thread" stacks which typically use more memory, but are capable of hosting
509 thread running in user mode, as well as any use-cases for kernel stacks.
520 - :c:macro:`ARCH_KERNEL_STACK_RESERVED`: default no reserved space
521 - :c:macro:`ARCH_THREAD_STACK_RESERVED`: default no reserved space
522 - :c:macro:`ARCH_KERNEL_STACK_OBJ_ALIGN`: default align to
524 - :c:macro:`ARCH_THREAD_STACK_OBJ_ALIGN`: default align to
526 - :c:macro:`ARCH_THREAD_STACK_SIZE_ALIGN`: default round up to
532 zero-sized depending on configuration. There are always two main parts:
538 Some architectures may need to carve-out reserved memory at runtime from the
541 Such carve-outs will always be tracked in ``thread.stack_info.start``.
548 .. code-block:: none
550 +---------------------+ <- thread.stack_obj
552 +---------------------+
553 | Carved-out memory |
554 |.....................| <- thread.stack_info.start
557 |.....................| <- thread's current stack pointer
560 |.....................| <- Initial stack pointer. Computable
562 +---------------------| <- thread.userspace_local_data
563 | Thread-local data |
564 +---------------------+ <- thread.stack_info.start + thread.stack_info.size
574 HW-based stack overflow detection
590 provide some kind of hardware-based stack overflow protection, and enable the
593 Two forms of HW-based stack overflow detection are supported: dedicated
594 CPU features for this purpose, or special read-only guard regions immediately
611 CPU-based stack overflow detection
612 ----------------------------------
619 Guard-based stack overflow detection
620 ------------------------------------
631 MMU-based systems should not reserve RAM for the guard region and instead
632 simply leave an non-present virtual page below every stack when it is mapped
636 .. code-block:: none
638 +-----------------------------+ <- thread.stack_obj
640 +-----------------------------+
641 | Guard carve-out |
642 |.............................| <- thread.stack_info.start
646 Guard carve-outs for kernel stacks are uncommon and should be avoided if
649 * The same stack may be re-purposed to host a user thread, in which case
657 completely overshooting a minimally-sized guard and corrupting adjacent
666 * A separate fixed-sized privilege mode stack, specified by
670 be able to be placed before it, with support for carve-outs if necessary.
684 ``thread.stack_info`` always tracks the user-accessible part of the stack
688 Non power-of-two memory region requirements
689 -------------------------------------------
691 On systems without power-of-two region requirements, the reserved memory area
695 .. code-block:: none
697 +------------------------------+ <- thread.stack_obj
699 +------------------------------+
701 +------------------------------+
702 | Guard carve-out (if needed) |
705 +------------------------------| <- thread.stack_obj +
709 The guard region, and any carve-out (if needed) would be configured as a
710 read-only region when the thread is created.
723 memory, each with non-present virtual guard pages below them to catch runtime
735 Power-of-two memory region requirements
736 ---------------------------------------
748 enabled. For every thread stack found in the system, a corresponding fixed-size
752 laid out the same way as other kernel-only stacks.
754 .. code-block:: none
756 +-----------------------------+ <- z_priv_stack_find(thread.stack_obj)
758 +-----------------------------+
759 | Guard carve-out (if needed) |
763 +-----------------------------+ <- z_priv_stack_find(thread.stack_obj) +
767 +-----------------------------+ <- thread.stack_obj
768 | MPU guard carve-out |
770 |.............................| <- thread.stack_info.start
774 The guard carve-out in the thread stack object is only used if the thread is
782 To support user mode threads, several kernel-to-arch APIs need to be
921 a ``g``/``G`` packets which will be sent back to GDB. The format of
922 the G-packet is architecture specific. Consult GDB on what is
925 * Note that, for most architectures, a valid G-packet must be returned
931 * This takes a G-packet sent by GDB and populates the hardware
932 registers with values from the G-packet.
957 in ROM or flash that cannot be modified at runtime. Consult
978 * :c:macro:`GDB_MEM_REGION_RO`: region is read-only.
980 * :c:macro:`GDB_MEM_REGION_RW`: region is read-write.
984 and read/write can be done byte-by-byte.
989 Timing subsection
992 .. doxygengroup:: arch-timing
997 .. doxygengroup:: arch-threads
999 .. doxygengroup:: arch-tls
1004 .. doxygengroup:: arch-pm
1006 Symmetric Multi-Processing
1009 .. doxygengroup:: arch-smp
1014 .. doxygengroup:: arch-irq
1019 .. doxygengroup:: arch-userspace
1024 .. doxygengroup:: arch-mmu
1029 .. doxygengroup:: arch-misc
1034 .. doxygengroup:: arch-gdbstub