Limit I/DCache line size options' value to
[2, UINT32_MAX] at Kconfig level instead of having
to check the value in code needlessly.
Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Across the tree, I/DCACHE_LINE_SIZE is required at compile-time for
macros, compiler attributes, & linker scripts to function correctly
even if run-time cache line detection is available.
So remove the dependency of ICACHE_LINE_SIZE on
ICACHE_LINE_SIZE_DETECT=n, and of DCACHE_LINE_SIZE on
DCACHE_LINE_SIZE_DETECT=n.
DCACHE_LINE_SIZE_DETECT & ICACHE_LINE_SIZE_DETECT Kconfig options
enable querying some SoC register for finding the i/d-cache line size
at the expense of taking more memory and code and a slightly
increased boot time.
Add new hidden options D/ICACHE_LINE_SIZE_DETECT_SUPPORT only selected
by the software component (arch/SoC layer, driver) implementing the system
cache API.
Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Vendor HAL interrupt handlers are often entered without their vector
number and have to discover it themselves. On Cortex-M the IPSR
register answers that, but on Cortex-A/R with a GIC the INTID exists
only at acknowledge time inside the ISR wrapper. The Renesas RZ SoCs
work around this today by selecting ARM_CUSTOM_INTERRUPT_CONTROLLER
with pass-through z_soc_irq_* wrappers around the standard GIC driver,
purely to intercept the ack/eoi moments and log the INTID into a
fixed-depth side stack for the FSP HAL, duplicated across six SoCs.
Add k_irq_get_active(), backed by arch_irq_get_active(): the
interrupt line whose handler is executing on the current CPU, or
K_IRQ_ACTIVE_NONE outside interrupt context. The capability symbol
ARCH_HAS_IRQ_GET_ACTIVE only promises the query; whether an
architecture reads it from a register or records it in the dispatch
path is its own business.
On Cortex-A/R recording is the only option, so the implementation is
gated behind an arch-level opt-in, ARM_TRACK_ACTIVE_IRQ, keeping the
cost decision where the cost lives: the shared ISR wrapper publishes
the acknowledged INTID in a per-CPU field of _cpu_arch and keeps the
previous value on the exception stack across the dispatch, so nested
interrupts unwind to the preempted INTID and the outermost exit back
to "none". The stored value is biased by one so the zero-initialized
boot state reads as "none" on every CPU without explicit
initialization, including secondary SMP cores. The wrapper records
whatever get_active returned, so it works with both the GIC and a
custom interrupt controller. Cost is zero when the option is off and
a few instructions per interrupt entry and exit when on.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Drivers that need to touch an interrupt's latched pending state
currently reach into the interrupt controller themselves.
NVIC_ClearPendingIRQ() alone appears at 88 call sites across 50 files
under drivers/, NVIC_SetPendingIRQ() at 34 (26 of them in
drivers/counter/, which pends its own IRQ to fire an alarm whose
deadline has already passed) and NVIC_GetPendingIRQ() at 11. Each
site pulls cmsis_core.h and a CONFIG_CPU_CORTEX_M guard into
otherwise portable code, and several counter drivers had already
written private GIC-or-NVIC dispatch helpers for exactly these
operations.
Add k_irq_set_pending(), k_irq_clear_pending() and k_irq_is_pending()
as ALWAYS_INLINE wrappers over matching arch_irq_* functions, and
implement them for the ARM NVIC (AArch32 Cortex-M) and the GIC
(AArch32 Cortex-A/R and AArch64), where the GIC driver already
exported all three as arm_gic_irq_*.
The k_ prefix is deliberate: vendor HAL headers already declare
plain irq_set_pending()/irq_clear_pending() as their own functions
(the Realtek Ameba ROM ABI, pico-sdk's hardware/irq.h), and several
drivers carry private static helpers or API struct members with the
bare names. A namespaced API collides with none of them, needs no
macro tricks, and no renaming of existing code.
The operations are gated on a single capability symbol,
CONFIG_ARCH_HAS_IRQ_PENDING_OPS, so an unported target fails to
build instead of silently doing nothing. Both implemented backends
support all three operations; should an architecture with partial
support materialize (a RISC-V PLIC can report pending state but only
clears it by claiming, and cannot latch from software), the symbol
can be split then.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Xtensa architecture does not have native inter-processor
interrupts and must rely on mechanism on SoC or board to do
that. Because of this, the architecture should not select
CONFIG_ARCH_HAS_DIRECTED_IPIS and should let SoC or board
layer to do that, where CONFIG_SCHED_IPI_SUPPORTED is also
being selected.
Note that CONFIG_XTENSA_LAZY_HIFI_SHARING is now dependent
on CONFIG_ARCH_HAS_DIRECTED_IPIS as it uses directed IPI.
Due to that it keeps sending IPI under the other has saved
HIFI state, it is not really appopriate to broadcast IPIs.
That's why it can only be enabled when directed IPI is
supported.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of defaulting to 0 in the absence of a devicetree value, set
cache line size to the arch bit width which is a good proxy for cache
line size, and it's safer to use in code.
This default will also eliminate the need for many redundant checks
across the tree of CACHE_LINE_SIZE's value.
Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Both architectures wait for the interrupt with interrupts enabled (x86
"sti; hlt", Xtensa "waiti 0"), so the wake-up ISR runs before the
idle-exit hook and can reschedule away from the idle thread. The CPU load
module therefore closes the idle window at ISR entry instead, which means
these architectures need to emit sys_trace_isr_enter().
- x86: the ia32 interrupt stub already emits the hook, but only under
CONFIG_TRACING_ISR. Emit it under CONFIG_SYS_IDLE_HOOKS as well. Also
restore the idle-exit hook after the halt as a fallback for a wake-up
that ran no ISR; closing the window is idempotent, so it is a no-op in
the common case. Only ia32 is enabled: intel64 has no ISR entry hook.
- Xtensa: the interrupt entry had no hook at all. Emit
sys_trace_isr_enter() from the common C interrupt handler, which also
gives Xtensa the ISR tracing it was missing.
Select ARCH_HAS_CPU_IDLE_HOOKS from both, and document in the capability's
help text the two ways an architecture can close the idle window.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The idle-hook CPU load backend requires the architecture idle path to
emit both the sys_trace_idle() and the sys_trace_idle_exit() hooks, and
to run the exit hook before servicing the interrupt that woke the CPU.
Consumers expressed this as a hard-coded architecture allowlist
(CPU_CORTEX_M || RISCV || CPU_CORTEX_A || XTENSA), which is opaque and,
as it turns out, inaccurate.
Introduce a hidden ARCH_HAS_CPU_IDLE_HOOKS capability and select it from
the architectures that actually satisfy both requirements: Arm Cortex-M,
Arm64 and RISC-V. All three wait for the interrupt with interrupts
locked, so the exit hook always closes the idle period before any ISR
can run.
This also corrects the allowlist, which claimed support that never
worked:
- Xtensa emits both hooks, but waits with "waiti 0", which enables
interrupts. The wake-up ISR can therefore context switch away before
the exit hook runs and the idle period is never closed.
- The aarch32 Cortex-A/R idle path emits only the enter hook, so idle
time is never accumulated at all.
On both, the idle-hook backend reported a constant 100% load. This is
covered by tests/lib/cpu_load, which fails on those targets when the
idle-hook backend is forced.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
ARCH_SUPPORTS_ROM_OFFSET is a hidden architecture-capability option, but
it was expressed as a reverse dependency on a hard-coded arch list
(ARM, X86, ARM64, RISCV, ARC) defaulting to y. This is inconsistent with
the surrounding ARCH_SUPPORTS_* symbols (e.g. ARCH_SUPPORTS_ROM_START),
which are selected by the architectures that provide the capability, and
the allowlist drifts as architectures are added.
Turn it into a plain selected capability symbol and have the supporting
architectures select it, matching the established convention. No
functional change.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
ISR_TABLES_LOCAL_DECLARATION_SUPPORTED gated its availability on a
hard-coded "List of currently supported architectures" (ARM, ARM64,
RISCV). Whether an architecture supports local declaration of interrupt
tables placed by the linker is an arch property, so the arch should
declare it rather than have the option carry an allowlist that drifts.
Introduce a hidden ARCH_HAS_ISR_TABLES_LOCAL_DECLARATION capability
symbol, have the supporting architectures select it, and depend the
supported symbol on the capability instead of the arch list. The
toolchain and userspace dependencies are unchanged. No functional change.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
CONFIG_SEMIHOST depended on a hard-coded list of architectures
(ARM, ARM64, RISCV, XTENSA). Each of these ships its own semihosting
backend under arch/*/core/semihost.c, so providing a semihosting
implementation is an architecture property that the arch should declare,
rather than having the common option maintain an allowlist that a new
arch adding a backend must remember to update.
Introduce a hidden ARCH_HAS_SEMIHOST capability symbol, have the
architectures that implement semihosting select it, and depend SEMIHOST
on the capability instead of the arch list. No functional change.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
IRQ_OFFLOAD_NESTED defaulted to y based on a hard-coded list of
architectures (ARM64, X86, RISCV, XTENSA). Whether irq_offload() may
legally be called in interrupt context to cause a synchronous nested
interrupt is an architecture property, so the arch itself should declare
it rather than have the option maintain an allowlist that drifts.
Introduce a hidden ARCH_HAS_IRQ_OFFLOAD_NESTED capability symbol, have
the architectures whose irq_offload() supports nesting select it, and key
the default of IRQ_OFFLOAD_NESTED off the capability instead of the list.
No functional change.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The OpenRISC linker script already implements CODE_DATA_RELOCATION
support, but the Kconfig symbol was never selected, preventing the
feature from being enabled.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
There can be platforms with a dcache or icache, but
without options for cache management. It that case
we should still be able to use the DCACHE_LINE_SIZE
without CACHE_MANAGEMENT if we want to use it to
align buffers for performance.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Add an AArch64 PMUv3 implementation behind CONFIG_ARM64_PMUV3 (pmuv3.c):
probe ID_AA64DFR0_EL1, calibrate CPU frequency (PMCCNTR_EL0 vs the
generic timer), and provide per-CPU counter configuration, enable/disable,
overflow handling, and cycle counter access. Initialization is explicit
via pmu_init() on each logical CPU that uses the PMU (no SYS_INIT).
Introduce include/zephyr/pmu.h for the portable pmu_*() API.
Architectural PMUv3 event codes (PMU_EVT_* in 0x00-0x1F) and
PMCR/PMUSERENR bit defines live in include/zephyr/arch/arm64/pmuv3.h for
AArch64 builds.
Add ARCH_HAS_PMU in arch/Kconfig (Cortex-A profiles select it); enable
CONFIG_ARM64_PMUV3 for the PMUv3 driver backend. Register access uses
explicit MRS/MSR inlines instead of read_sysreg()/write_sysreg()
statement expressions for static analysis.
Builds for versal_apu, versalnet_apu, and versal2_apu. On QEMU, PMU
access is often unavailable (-ENOTSUP). On Versal Net APU hardware with
PMU usable at the current EL, initialization succeeds.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
Enabling the FPU forces the choice between CONFIG_FP_HARDABI
and CONFIG_FP_SOFTABI. Both of these options allow the compiler
to generate FP instructions. As a result, all threads must have
the K_FP_REGS options bit set because we can not predict where
the compiler will generate those instructions.
The forced enablement is keyed off those ABI Kconfig options
and not FPU sharing nor the FPU enablement. This leaves the
option open for a future (as yet not implemented) case where
someone might want FPU support but not have the compiler generate
any FPU instructions at all.
Fixes#108793
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
Previously, ATOMIC_OPERATIONS_C was selected for RISC-V whenever the
'A' (atomic) ISA extension (RISCV_ISA_EXT_A) was absent. This caused
a conflict on platforms that lack the 'A' extension but still provide
their own arch-level atomic implementation via ATOMIC_OPERATIONS_ARCH
(e.g. future RISC-V SoCs with custom atomic support).
Add !ATOMIC_OPERATIONS_ARCH to the select condition so that the
generic C fallback (interrupt-locking) is only chosen when neither
the ISA extension nor an arch-specific implementation is available.
This condition creates a Kconfig dependency cycle:
RISCV selects ATOMIC_OPERATIONS_C if !ATOMIC_OPERATIONS_ARCH
=> ATOMIC_OPERATIONS_C depends on !ATOMIC_OPERATIONS_ARCH
=> ATOMIC_OPERATIONS_ARCH depends on SMP (fvp_base_revc_2xaem board)
=> SMP depends on !ATOMIC_OPERATIONS_C
Break the cycle by removing 'depends on !ATOMIC_OPERATIONS_C' from
SMP in kernel/smp/Kconfig. This is safe because ATOMIC_OPERATIONS_C
is now only selected when ATOMIC_OPERATIONS_ARCH is absent, so the
two symbols are mutually exclusive by construction. The existing
BUILD_ASSERT(!IS_ENABLED(CONFIG_SMP)) in lib/os/atomic_c.c provides
a compile-time backstop against any misconfiguration.
Suggested-by: Nicolas Pitre <npitre@baylibre.com>
Signed-off-by: Lingutla Chandrasekhar <lingutla@qti.qualcomm.com>
This change enables per thread stack canary for RISC-V.
RISC-V GCC accesses the stack canary via a fixed offset from the
thread pointer (tp) when -mstack-protector-guard=tls is used. The
compiler emits code equivalent to:
lw t0, 0(tp) # load canary from tp+0
Additionally, tp is zeroed in arch_kernel_init() when TLS is enabled,
which means any C function called before thread setup completes (such
as z_early_rand_get or data_copy_xip_relocation) would fault trying
to access the canary.
Introduce STACK_CANARIES_TLS_PREPEND, which places the
.stack_chk.guard section at offset 0 of the TLS block, before .tdata
and .tbss. The compiler flags -mstack-protector-guard-reg=tp and
-mstack-protector-guard-offset=0 are passed so GCC generates the
correct canary access.
With STACK_CANARIES_TLS_PREPEND the per-thread TLS block layout is:
tp --> +------------------+ offset 0
| .stack_chk.guard | (__stack_chk_guard)
+------------------+
| .tdata | (initialized TLS data)
+------------------+
| .tbss | (zero-initialized TLS data)
+------------------+
The RISC-V reset path is extended to initialize tp before any C code
runs by allocating a TLS area on the boot stack and calling
arch_riscv_early_tls_stack_update(). Early boot functions that run
before tp is set up (z_early_rand_get, data_copy_xip_relocation) are
marked FUNC_NO_STACK_PROTECTOR to avoid canary access before tp is
valid.
Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
The LRU eviction algorithm needs to catch the first access to a loaded
page in order to call k_mem_paging_eviction_accessed() and move that
page to the tail of the queue. On ARM64 this is done with the MMU's
Access Flag: clearing AF causes a distinct fault on the next access.
On x86 there is no access-flag fault. The Accessed bit (PTE bit 5) is
set by hardware on access but never traps. The only way to force a
fault is to clear the Present bit, which already encodes the
"paged out" state — so a new state is needed:
PTE == 0 -> unmapped
P=0, A=1, upper=location -> paged out
P=0, G=1, upper=PFN -> LRU-tracked (new)
P=1 -> normally mapped
Bit G (Global, bit 8) is never set by Zephyr on x86 (CR4.PGE is not
used), so it is free to use as a private marker when P=0. No existing
PTE state needs to be displaced. This stays out of the way of the
KPTI path (which uses the PAT bit) and of the permission-backup bits
(IGNORED0..2) used for memory domain handling.
arch_page_info_get(addr, NULL, clear_accessed=true) is overloaded
under CONFIG_EVICTION_LRU to both query the prior flags and transition
the page to the LRU-tracked state via a new helper that updates all
domain ptables. arch_page_location_get() recognizes the tracked state
as paged-in so the core demand-paging code treats the page as resident.
The page fault handler intercepts LRU-tracking faults in-line before
k_mem_page_fault() dispatch: restore P, clear the tracking bit, and
call k_mem_paging_eviction_accessed() directly. This avoids the risk
of recursing through do_page_fault() with z_mm_lock held.
KPTI co-exists with demand paging but its PTE encoding is not yet
wired up to the LRU state, so tracking is gated on !X86_KPTI for now.
Fixes: #75132
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Deprecates these Kconfigs and emits a deprecated warning when
either of them are changed from their defaults (on a different
symbol, due to Kconfig limitations)
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Adds a Kconfig which will be used to determine where the source of
truth will be for RAM configuration for a board target, to allow
moving to a pure DTS approach
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Implement arch_pm_s2ram_suspend() and arch_pm_s2ram_resume() for
RISC-V, mirroring the ARM Cortex-M implementation. The assembly
saves and restores callee-saved GPRs, FP registers (when enabled),
and critical CSRs (mstatus, mtvec, mscratch, mie/mtvt).
Both CLIC (mtvt) and non-CLIC (mie) interrupt controller
configurations are handled via conditional compilation.
The CSR_MTVT define is placed in the shared csr.h header for
reuse across the architecture.
Signed-off-by: William Markezana <william.markezana@gmail.com>
It makes sense that userspace threads shouldn't cause system level
exceptions, but there is no real dependency on that choice. Moreover
userspace applications can anyway cause exceptions by other means.
Leave the decision to the system configuration instead of making it a
hard requirement.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Allow to use a switch-case instead of an array holding ISR entries.
When most of IRQs are not used, they share the same, default entry.
It results in most of the ISR array entries being identical duplicates.
This change allows to use dynamically generated function (after first
linker pass) that uses switch-case instead of a full array.
Default entries are handled only once, in a default section.
Used IRQs have their own case sections.
This can help reduce binary size.
Signed-off-by: Adam Szczygieł <adam.szczygiel@nordicsemi.no>
With kernel coherence enabled, it is possible that the stack has
been allocated on uncached area. This has implications on
performance as memory access is not cached.
This adds a kconfig to force the indicated stack pointer of
the allocated thread stack object to be in cached area.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Clear the TLS base pointer (r10) in arch_kernel_init.
Allocate the TLS area in arch_tls_stack_setup.
Set the TLS base pointer register (r10) in arch_new_thread.
Set ARCH_HAS_THREAD_LOCAL_STORAGE for config OPENRISC.
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch adds support for the OpenRISC 1000 (or1k) architecture: a
MIPS-like open hardware ISA which was first introduced in 2000.
The thread switching implementation uses the modern Zephyr thread "switch"
architecture.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
This was just a pedantic setting. I mean, of course it makes no sense
to have thread FPU management state features built when you aren't
including the scheduler in the build.
...unless you want to unit-test the context switch code without
tripping over itself on the way into the test code. In fact lots of
unit testing of low level primitives can be done with
MULTITHREADING=n.
Remove the dependency. It isn't actually doing anything useful.
Signed-off-by: Andy Ross <andyross@google.com>
ISR_TABLES_LOCAL_DECLARATION depends on GEN_IRQ_VECTOR_TABLE but
this is not enforced in Kconfig.
Building without the GEN_IRQ_VECTOR_TABLE and with LOCAL_DECLARATION
will produce the following misleading static assertion error:
"CONFIG_IRQ_VECTOR_TABLE_JUMP_BY_{ADDRESS,CODE} not set"
As the LOCAL_DECLARATION macros expect GEN_IRQ_VECTOR_TABLE to be
enabled. LOCAL_DECLARATION also depends on GEN_ISR_TABLES but that
is a dependency of GEN_IRQ_VECTOR_TABLE already.
Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
The MAX32 RV32 core does not implement the fence instruction used by the
RISC-V synchronization intrinsic, so don't enable the builtin barriers for
that target.
Signed-off-by: Pete Johanson <pete.johanson@analog.com>
Select ARCH_SUPPORTS_COREDUMP_THREADS (if !SMP) and
ARCH_SUPPORTS_COREDUMP_STACK_PTR for RISC-V, and implement
arch_coredump_stack_ptr_get().
This enables CONFIG_DEBUG_COREDUMP_MEMORY_DUMP_THREADS and
CONFIG_DEBUG_COREDUMP_THREAD_STACK_TOP.
For non-current threads, return thread->callee_saved.sp.
For the faulting current thread in stack-top mode, return the
exception-time SP from z_riscv_get_sp_before_exc() (cached during
arch_coredump_info_dump()) instead of thread->callee_saved.sp,
which reflects switch-time state.
Signed-off-by: Mirai SHINJO <oss@mshinjo.com>
Use CONFIG_CACHE_HAS_MIRRORED_MEMORY_REGIONS instead.
The new kconfig reflects more correctly on what is going on
in hardware. Also, this is not enabled by default if CPU
cache is not coherent. CPU cache can be incoherent and yet
there are no mirrored memory regions. Those relying on this
deprecated default behavior has their config adding
CONFIG_CACHE_HAS_MIRRORED_MEMORY_REGIONS separately.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This allows SoC to define their custom cache related functions
and are used by sys_cache_*() functions.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
arch_mem_coherent() is cache related so it is better to move it
under cache subsys. It is renamed to sys_cache_is_mem_coherent()
to reflect this change.
The only user of arch_mem_coherent() is Xtensa. However, it is
not an architecture feature. That's why it is moved to the cache
subsys.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The Zephyr linker script usually puts something before
z_mapped_start (where .text is), for example, vecbase vectors.
So we need to reserve those space or else k_mem_map() would be
mapping those which may result in faults.
To avoid mapping there, CONFIG_ARCH_HAS_RESERVED_PAGE_FRAMES
needs to be used. Since it is common when MMU is enabled, we
should enable it by default using imply. All current Xtensa
MMU SoCs all have this selected anyway. Using 'imply' instead
of 'select' is to allow it to be disabled if so desired.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
C99 has been the minimum required C standard version for Zephyr since
its inception. After multiple attempts and discussions, a decision has
been made to upgrade to C17 going forward.
This commits replaces the default C standard from C99 to C17 in the
configuration and build system, and deprecates support for the older
standards.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Adds a new kconfig CONFIG_MEM_DOMAIN_HAS_THREAD_LIST so that
only the architectures requiring to keep track of threads in
memory domains will have the necessary list struct inside
the memory domain structs. Saves a few bytes for those arch
not needing this.
Also rename the struct fields to be most descriptive of what
they are.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
CONFIG_FLASH_SIZE and CONFIG_FLASH_BASE_ADDRESS symbols were not defined in
native_sim even though it has a flash controller and flash defined.
Signed-off-by: Flavio Ceolin <flavio@hubble.com>
Select ARCH_SUPPORTS_COREDUMP_STACK_PTR on xtensa, and provide an
implementation for the arch_coredump_stack_ptr_get function.
Signed-off-by: Mark Holden <mholden@meta.com>
Not really a kernel feature, more for architecture, which is reflected
in how XIP is enabled and tested. Move it to architecture code to keep
which much of the 'implementation' and usage is.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
In order to allow kernel created threads (such as main and idle threads)
to make use of hardware shadow stack implementation, add an interface
for them.
This patch basically provides an infra that architectures need to
implement to provide hardware shadow stack.
Also, main and idle threads are updated to make use of this interface
(if hardware shadow stacks are enabled).
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
