Clarify the CONFIG_XIP description to explain its effect on LMA/VMA
alignment for .text/.rodata and RAM usage, and note that it should be
disabled for images copied into RAM before execution.
Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Fixes various issues with Kconfigs, including:
- Using the wrong indentation
- Not having [EXPERIMENTAL] in the prompt, or not having it at
the end
- Wrongly stating the CONFIG_EXPERIMENTAL is needed to enable
an experimental Kconfig
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Add a common hook declaration and Kconfig switch for firmware
arguments provided by architecture startup code.
The hook receives an architecture-provided argument array and count.
This keeps the common interface independent from register naming used
by a specific architecture.
On ARM64, preserve x0-x3 from the primary CPU reset path before
startup code reuses those registers. The saved values are stored only
after the primary CPU path is selected and are passed to the hook after
RAM has been initialized for C code. Secondary CPUs do not update the
saved storage.
Signed-off-by: Vladyslav Goncharuk <vladyslav_goncharuk@epam.com>
Assisted-by: Codex:gpt-5
Add TriCore architecture port supporting TC1.6P and TC1.8P core
variants used in Infineon AURIX TC3x and TC4x SoC families.
Includes context switching using TriCore upper/lower context save
areas (CSA), interrupt management, trap and exception handling,
syscall interface, reset vector and linker script.
Supports cooperative and preemptive threading, nested interrupt
handling with priority-based preemption.
Signed-off-by: Christoph Seitz <christoph.seitz@infineon.com>
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
The Cortex-A/R cores previously shared the Cortex-M irq_offload
implementation (arch/arm/core/irq_offload.c), which stores the offloaded
routine and parameter in global state and brackets the triggering svc
with k_sched_lock(). This is unsuitable for Cortex-A/R because:
On SMP, CPUs might need to run their offloaded functions at the same
time (for eg. the smp_abort test) so a single global routine/parameter
pair cannot be used. Also, k_sched_lock() is illegal in interrupt context,
so the shared backend cannot honour CONFIG_IRQ_OFFLOAD_NESTED
(irq_offload() called from an ISR, for eg. test_nested_irq_offload test).
Add a dedicated cortex_a_r/irq_offload.c that fixes the above by:
1. keeping the offloaded routine/parameter per-CPU, indexed by
_current_cpu->id, so concurrent CPUs no longer interfere with each
other.
2. using arch_irq_lock()/arch_irq_unlock() instead of k_sched_lock() to
pin the caller to its CPU while the per-CPU slot is written and the
svc is taken, while remaining legal from interrupt context. On
Cortex-A/R the SVC is not masked by CPSR.I. So it still traps with
interrupts locked.
The offloaded routine/parameter are kept in a per-CPU slot rather than
passed in registers (as arm64 does) to keep this change self-contained
in C and to avoid modifying the shared SVC exception entry used for
context switch, oops and syscalls.
Build the new file for Cortex-A/R, and select ARCH_HAS_IRQ_OFFLOAD_NESTED
for CPU_AARCH32_CORTEX_A and CPU_AARCH32_CORTEX_R.
Signed-off-by: Silesh C V <silesh@alifsemi.com>
Add Hexagon DSP architecture support to Zephyr RTOS, targeting the
Qualcomm Hexagon V67+ ISA running as a guest under the H2 hypervisor.
This includes:
- Architecture scaffolding (Kconfig, CMakeLists, arch selection)
- Public headers (arch.h, thread.h, exception.h, error.h)
- Core runtime: context switch, interrupt/exception handling, idle, TLS
- Memory management stubs for flat-memory H2 guest model
- SoC support for QEMU hexagon virt machine
- CMake/LLVM toolchain integration for hexagon cross-compilation
Hexagon uses H2's GEVB (Guest Event Vector Base) for interrupt dispatch
rather than a traditional function-pointer vector table, so
GEN_IRQ_VECTOR_TABLE is disabled by default.
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
A thread actively running on another CPU at panic time was previously
invisible to real debugging: coredump only captured the panicking CPU's
exception frame, so every other thread's registers came from its
k_thread.callee_saved struct -- correct for genuinely sleeping threads,
but stale (reflecting whenever it last voluntarily context switched) for
one that's actually running elsewhere right now.
Add CONFIG_DEBUG_COREDUMP_SMP_FREEZE_CPUS (default y where the arch sets
ARCH_SUPPORTS_COREDUMP_SMP_FREEZE, i.e. arm64 Cortex-A SMP). On panic,
coredump() freezes every other online CPU before dumping and thaws them
after the memory-region walk, and emits each frozen CPU's live registers
as a new coredump section (COREDUMP_CPU_SNAPSHOT_HDR_ID, tagged with CPU
index and thread pointer, reusing the arch-info block register layout).
The panicking CPU (never frozen, since freeze only targets other CPUs)
emits a zero-payload marker recording only which thread was panicking
there, which the host side uses to identify it unambiguously.
arm64 implementation (arch/arm64/core/smp.c, coredump.c): send a new SGI
to every other online CPU. Each handler captures its exact live state --
x0-x18/lr/spsr/elr via the arch_esf that _isr_wrapper() stashes at a
fixed, nesting-independent slot on its IRQ stack, plus x19-x29 via inline
asm (valid per AAPCS64) -- then spins holding whatever it held before
being frozen, untouched, until the dump finishes, and resumes via the
standard exception-return path exactly where it was interrupted. This
matters because a panic here can be recoverable (this tree's own
coredump_threads test doesn't halt/reboot after dumping).
The SGI uses a deliberately low priority (SGI_COREDUMP_FREEZE_PRIO), not
IRQ_DEFAULT_PRIORITY: a frozen CPU never returns from its handler so
_isr_wrapper() never EOIs, and per GIC priority rules only a strictly
higher-priority interrupt can preempt a still-active one. At the default
priority a frozen CPU could not service same-priority peripheral
interrupts (confirmed on hardware as Ethernet TX-done starvation during
the UDP backend); the lowest usable priority lets everything else keep
making progress while a CPU waits.
The freeze/thaw handshake uses two separate per-CPU signals: freeze_state
(IDLE/REQUESTED/CAPTURED) and a dedicated release_requested flag that
only thaw writes. Kept separate so a late-arriving CPU (whose SGI was
delayed past the freeze-side timeout) still sees a release signal instead
of stomping it with its own CAPTURED update and spinning forever; thaw
sets release_requested unconditionally for every other CPU. The handler
wait is also bounded by a 60-second wall-clock backstop (k_cycle_get_32(),
safe from any context) so no CPU is ever stuck indefinitely. A CPU that
never responds within the freeze-side timeout (never booted, or stuck
with IRQs masked) is skipped and never blocks the dump.
The host coredump log parser learns to parse the new snapshot section.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
Direct interrupts are an optional architecture feature: only ARC, ARM
(aarch32), RISC-V, x86 ia32 and the POSIX/native boards implement the
ARCH_IRQ_DIRECT_CONNECT() and ARCH_ISR_DIRECT_DECLARE() hooks. There was
no way to express that dependency in Kconfig, so a symbol enabling code
that uses IRQ_DIRECT_CONNECT() had to enumerate the supporting
architectures itself, and the only capability test available to C code
was probing whether the arch hook macro happened to be defined.
Add ARCH_HAS_DIRECT_INTERRUPTS, selected by the architectures that
implement the hooks, and switch the gen_isr_table test over to it. Note
that the capability is not uniform across an architecture: x86 provides
it only on the 32-bit (ia32) variant, and arm64, xtensa, MIPS, SPARC and
RX do not provide it at all.
No functional change: the symbol is selected exactly where the arch hooks
are defined today.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
