michaelh/zephyr
Watch
1
0
Fork
You've already forked zephyr
 0
Code Releases Activity
zephyr/arch/riscv/core/reset.S

248 lines
5.9 KiB
ArmAsm
Raw Permalink Normal View History

arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
/*
* Copyright (c) 2016 Jean-Paul Etienne <fractalclone@gmail.com>
riscv32: riscv-privilege: integrate common code This commit moves code from fe310 platform into RISC-V privilege common folder. This way the code can be reused by other platforms in future. signed-off-by: Karol Gugala <kgugala@antmicro.com>
2018-06-10 19:02:14 +02:00
* Contributors: 2018 Antmicro <www.antmicro.com>
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
*
license: Replace Apache boilerplate with SPDX tag Replace the existing Apache 2.0 boilerplate header with an SPDX tag throughout the zephyr code tree. This patch was generated via a script run over the master branch. Also updated doc/porting/application.rst that had a dependency on line numbers in a literal include. Manually updated subsys/logging/sys_log.c that had a malformed header in the original file. Also cleanup several cases that already had a SPDX tag and we either got a duplicate or missed updating. Jira: ZEP-1457 Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c Signed-off-by: David B. Kinder <david.b.kinder@intel.com> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-01-18 17:01:01 -08:00
* SPDX-License-Identifier: Apache-2.0
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
*/
asm: update files with <zephyr/...> include prefix Assembler files were not migrated with the new <zephyr/...> prefix. Note that the conversion has been scripted, refer to #45388 for more details. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-09 13:56:13 +02:00
#include <zephyr/toolchain.h>
#include <zephyr/linker/sections.h>
#include <zephyr/arch/cpu.h>
build: namespace the generated headers with `zephyr/` Namespaced the generated headers with `zephyr` to prevent potential conflict with other headers. Introduce a temporary Kconfig `LEGACY_GENERATED_INCLUDE_PATH` that is enabled by default. This allows the developers to continue the use of the old include paths for the time being until it is deprecated and eventually removed. The Kconfig will generate a build-time warning message, similar to the `CONFIG_TIMER_RANDOM_GENERATOR`. Updated the includes path of in-tree sources accordingly. Most of the changes here are scripted, check the PR for more info. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-01-24 17:35:04 +08:00
#include <zephyr/offsets.h>
arch/riscv: Enable NMI delivery for SMRNMI hardware Add option to enable NMI delivery on boot for SMRNMI hardware. Changes: - Add CONFIG_RISCV_SMRNMI_ENABLE_NMI_DELIVERY Kconfig option - Define SMRNMI CSRs in arch/riscv/include/csr.h - Set NMIE bit during boot to enable NMI delivery SMRNMI hardware generates but doesn't deliver NMIs when NMIE=0 (default). This causes twister test failures and prevents handling of critical hardware events like watchdog NMIs and ECC errors. Setting NMIE=1 enables NMI delivery, but note that this implementation only sets the enable bit - it does not provide full SMRNMI support (no mnret instruction handling, no RNMI handlers). Users must implement proper RNMI handlers in SoC-specific code to avoid undefined behavior. Signed-off-by: Afonso Oliveira <afonsoo@synopsys.com>
2025-07-28 19:51:48 +01:00
#include <zephyr/arch/riscv/csr.h>
arch: riscv: add Supervisor-mode (S-mode) support Introduce CONFIG_RISCV_S_MODE to select Supervisor-mode execution. Add depends on !RISCV_S_MODE to RISCV_PMP since PMP CSRs are inaccessible from S-mode. Add an M-mode SBI shim (reset.S + sbi.S) that configures exception delegation, PMP, and counter access before dropping to S-mode via mret. The shim handles SBI_SET_TIMER ecalls from S-mode and forwards MTIP to STIP so the supervisor timer driver works without a full SBI firmware. Introduce privilege-level abstractions in isr.S (RV_CAUSE, RV_EPC, RV_STATUS, RV_TVAL, etc.) and update all runtime code that previously accessed M-mode-only CSRs (mcause, mtval, mstatus, mie, mip) to use the S-mode equivalents when CONFIG_RISCV_S_MODE is set. ARCH_EXCEPT in kernel context uses ebreak (cause=3, Breakpoint) instead of a direct z_riscv_fatal_error() call. In S-mode, ecall (cause=9) is kept in M-mode for SBI and never reaches the S-mode exception handler; a direct call with NULL esf caused the stack unwinder to crash into an infinite fault loop. ebreak is delegated to S-mode by our medeleg configuration; isr.S treats ebreak with t0=RV_ECALL_RUNTIME_EXCEPT the same way M-mode treats ecall-based ARCH_EXCEPT. Signed-off-by: Alexios Lyrakis <alexios.lyrakis@gmail.com>
2026-03-28 15:34:55 +00:00
#include <zephyr/arch/riscv/irq.h>
riscv: better abstraction for register-wide load/store opcodes Those are prominent enough that having RV_OP_LOADREG and RV_OP_STOREREG shouting at you all over the place is rather unpleasant and bad taste. Let's create pseudo-instructions of our own with assembler macros rather than preprocessor defines and only in assembly scope. This makes the asm code way more uniform and readable. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-22 14:09:55 -05:00
#include "asm_macros.inc"
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
arch: riscv: add Supervisor-mode (S-mode) support Introduce CONFIG_RISCV_S_MODE to select Supervisor-mode execution. Add depends on !RISCV_S_MODE to RISCV_PMP since PMP CSRs are inaccessible from S-mode. Add an M-mode SBI shim (reset.S + sbi.S) that configures exception delegation, PMP, and counter access before dropping to S-mode via mret. The shim handles SBI_SET_TIMER ecalls from S-mode and forwards MTIP to STIP so the supervisor timer driver works without a full SBI firmware. Introduce privilege-level abstractions in isr.S (RV_CAUSE, RV_EPC, RV_STATUS, RV_TVAL, etc.) and update all runtime code that previously accessed M-mode-only CSRs (mcause, mtval, mstatus, mie, mip) to use the S-mode equivalents when CONFIG_RISCV_S_MODE is set. ARCH_EXCEPT in kernel context uses ebreak (cause=3, Breakpoint) instead of a direct z_riscv_fatal_error() call. In S-mode, ecall (cause=9) is kept in M-mode for SBI and never reaches the S-mode exception handler; a direct call with NULL esf caused the stack unwinder to crash into an infinite fault loop. ebreak is delegated to S-mode by our medeleg configuration; isr.S treats ebreak with t0=RV_ECALL_RUNTIME_EXCEPT the same way M-mode treats ecall-based ARCH_EXCEPT. Signed-off-by: Alexios Lyrakis <alexios.lyrakis@gmail.com>
2026-03-28 15:34:55 +00:00
#ifdef CONFIG_RISCV_S_MODE
/* mcounteren bits */
#define MCOUNTEREN_CY BIT(0) /* cycle counter */
#define MCOUNTEREN_TM BIT(1) /* time counter */
#define MCOUNTEREN_IR BIT(2) /* instret counter */
#endif
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
/* exports */
riscv32: riscv-privilege: integrate common code This commit moves code from fe310 platform into RISC-V privilege common folder. This way the code can be reused by other platforms in future. signed-off-by: Karol Gugala <kgugala@antmicro.com>
2018-06-10 19:02:14 +02:00
GTEXT(__initialize)
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
GTEXT(__reset)
/* imports */
arch: _PrepC -> z_prep_c Rename to use common naming for z_prep_c applied to all architectures. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2023-12-08 07:55:21 -05:00
GTEXT(z_prep_c)
arch: riscv: core: Fix type riscv_cpu_wake_flag and riscv_cpu_sp are variables, not functions, so they should use the GDATA macro instead of the GTEXT macro. Otherwise, the linker will warn when LTO is enabled: ld.bfd: warning: type of symbol `riscv_cpu_wake_flag' changed from 2 to 1 in /tmp/cc39w5oK.ltrans0.ltrans.o ld.bfd: warning: type of symbol `riscv_cpu_sp' changed from 2 to 1 in /tmp/cc39w5oK.ltrans0.ltrans.o Signed-off-by: Tom Hughes <tomhughes@chromium.org>
2025-06-03 06:25:18 -07:00
GDATA(riscv_cpu_wake_flag)
GDATA(riscv_cpu_sp)
arch: introduce arch_secondary_cpu_init Different architecture are doing this in custom ways and using different naming conventions, unify this interface and make it part of the arch implementation for SMP. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2023-12-13 15:27:41 -05:00
GTEXT(arch_secondary_cpu_init)
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#ifdef CONFIG_RISCV_S_MODE_INTERNAL_SBI
arch: riscv: add Supervisor-mode (S-mode) support Introduce CONFIG_RISCV_S_MODE to select Supervisor-mode execution. Add depends on !RISCV_S_MODE to RISCV_PMP since PMP CSRs are inaccessible from S-mode. Add an M-mode SBI shim (reset.S + sbi.S) that configures exception delegation, PMP, and counter access before dropping to S-mode via mret. The shim handles SBI_SET_TIMER ecalls from S-mode and forwards MTIP to STIP so the supervisor timer driver works without a full SBI firmware. Introduce privilege-level abstractions in isr.S (RV_CAUSE, RV_EPC, RV_STATUS, RV_TVAL, etc.) and update all runtime code that previously accessed M-mode-only CSRs (mcause, mtval, mstatus, mie, mip) to use the S-mode equivalents when CONFIG_RISCV_S_MODE is set. ARCH_EXCEPT in kernel context uses ebreak (cause=3, Breakpoint) instead of a direct z_riscv_fatal_error() call. In S-mode, ecall (cause=9) is kept in M-mode for SBI and never reaches the S-mode exception handler; a direct call with NULL esf caused the stack unwinder to crash into an infinite fault loop. ebreak is delegated to S-mode by our medeleg configuration; isr.S treats ebreak with t0=RV_ECALL_RUNTIME_EXCEPT the same way M-mode treats ecall-based ARCH_EXCEPT. Signed-off-by: Alexios Lyrakis <alexios.lyrakis@gmail.com>
2026-03-28 15:34:55 +00:00
GTEXT(__m_mode_sbi_handler)
#endif
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
#if CONFIG_INCLUDE_RESET_VECTOR
SECTION_FUNC(reset, __reset)
/*
riscv32: riscv-privilege: integrate common code This commit moves code from fe310 platform into RISC-V privilege common folder. This way the code can be reused by other platforms in future. signed-off-by: Karol Gugala <kgugala@antmicro.com>
2018-06-10 19:02:14 +02:00
* jump to __initialize
* use call opcode in case __initialize is far away.
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
* This will be dependent on linker.ld configuration.
*/
riscv32: riscv-privilege: integrate common code This commit moves code from fe310 platform into RISC-V privilege common folder. This way the code can be reused by other platforms in future. signed-off-by: Karol Gugala <kgugala@antmicro.com>
2018-06-10 19:02:14 +02:00
call __initialize
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
#endif /* CONFIG_INCLUDE_RESET_VECTOR */
/* use ABI name of registers for the sake of simplicity */
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
#ifdef CONFIG_THREAD_LOCAL_STORAGE
/*
* Allocate a TLS area on the current stack, initialize it via
arch/riscv: fix early TLS setup and save callee-saved registers Fix the early TLS initialization sequence on RISC-V to correctly set up the thread pointer (tp) before any C code runs, and save/restore callee-saved registers as required by the ABI. Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
2026-04-01 15:02:05 -07:00
* arch_riscv_early_tls_stack_update(), set tp to point to it.
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
*/
.macro riscv_tls_init_early
arch/riscv: fix early TLS setup and save callee-saved registers Fix the early TLS initialization sequence on RISC-V to correctly set up the thread pointer (tp) before any C code runs, and save/restore callee-saved registers as required by the ABI. Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
2026-04-01 15:02:05 -07:00
/* Save s0/s1, else they get clobbered */
addi sp, sp, -16
sr s0, 0(sp)
sr s1, 8(sp)
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
mv s0, sp
call z_tls_data_size_asm
beqz a0, tls_skip\@
mv s1, a0
sub sp, sp, a0
mv a0, s0 /* arg0: stack_top */
mv a1, s1 /* arg1: tls_size */
call arch_riscv_early_tls_stack_update
tls_skip\@:
arch/riscv: fix early TLS setup and save callee-saved registers Fix the early TLS initialization sequence on RISC-V to correctly set up the thread pointer (tp) before any C code runs, and save/restore callee-saved registers as required by the ABI. Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
2026-04-01 15:02:05 -07:00
/* Restore s0/s1. sp intentionally stays below the TLS area so the
* runtime stack grows away from it. The 16-byte save frame above
* sp is abandoned.
*/
lr s1, 8(s0)
lr s0, 0(s0)
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
.endm
#endif /* CONFIG_THREAD_LOCAL_STORAGE */
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
/*
* Remainder of asm-land initialization code before we can jump into
* the C domain
*/
riscv32: riscv-privilege: integrate common code This commit moves code from fe310 platform into RISC-V privilege common folder. This way the code can be reused by other platforms in future. signed-off-by: Karol Gugala <kgugala@antmicro.com>
2018-06-10 19:02:14 +02:00
SECTION_FUNC(TEXT, __initialize)
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#ifndef CONFIG_RISCV_S_MODE_EXTERNAL_SBI
/*
* When entered directly in S-mode by an external bootloader/SBI, a0
* already holds the hart id per the RISC-V S-mode boot protocol
* (a0=hartid, a1=dtb), and mhartid would trap, so only read it here.
*/
arch: riscv: Add simple wrokaround to boot multicore system Just boot master core, halt others Signed-off-by: Huang Qi <757509347@qq.com>
2019-09-12 12:07:16 +00:00
csrr a0, mhartid
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#endif /* CONFIG_RISCV_S_MODE_EXTERNAL_SBI */
riscv: enable booting from non-zero indexed RISC-V hart RISC-V multi-hart systems that employ a heterogeneous core complex are not guaranteed to have the smp capable harts starting with a unique id of zero, matching Zephyr's sequential zero indexed cpu numbering scheme. Add option, RV_BOOT_HART to choose the hart to boot from. On reset, check the current hart equals RV_BOOT_HART: if so, boot first core. else, loop in the boot secondary core and wait to be brought up. For multi-hart systems that are not running a Zephyr mp or smp application, park the non zephyr related harts in a wfi loop. Signed-off-by: Conor Paxton <conor.paxton@microchip.com>
2023-01-16 13:53:06 +00:00
li t0, CONFIG_RV_BOOT_HART
beq a0, t0, boot_first_core
j boot_secondary_core
arch: riscv: Add simple wrokaround to boot multicore system Just boot master core, halt others Signed-off-by: Huang Qi <757509347@qq.com>
2019-09-12 12:07:16 +00:00
arch/riscv: Boot secondary CPUs for SMP support Secondary CPUs are now initialised and made available to the system. If the system has more CPUs than configured via CONFIG_MP_NUM_CPUS, those are still left looping as before. Some implementations of `soc_interrupt_init` also changed to use `arch_irq_lock` instead of `irq_lock`. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2021-12-29 10:22:48 -08:00
boot_first_core:
arch: riscv: Add simple wrokaround to boot multicore system Just boot master core, halt others Signed-off-by: Huang Qi <757509347@qq.com>
2019-09-12 12:07:16 +00:00
kconfig: Rename CONFIG_FLOAT to CONFIG_FPU This commit renames the Kconfig `FLOAT` symbol to `FPU`, since this symbol only indicates that the hardware Floating Point Unit (FPU) is used and does not imply and/or indicate the general availability of toolchain-level floating point support (i.e. this symbol is not selected when building for an FPU-less platform that supports floating point operations through the toolchain-provided software floating point library). Moreover, given that the symbol that indicates the availability of FPU is named `CPU_HAS_FPU`, it only makes sense to use "FPU" in the name of the symbol that enables the FPU. Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
2020-04-23 17:27:24 +09:00
#ifdef CONFIG_FPU
riscv: Add support for floating point This change adds full shared floating point support for the RISCV architecture with minimal impact on threads with floating point support not enabled. Signed-off-by: Corey Wharton <coreyw7@fb.com>
2020-03-11 18:15:29 -07:00
/*
* Enable floating-point.
*/
riscv: use simplest asm expression when possible Let's take advantage of assembler pseudoinstructions: - convert `addi rd, rs, 0` to `mv rd, rs` - convert `jal x0, somewhere` to `j somewhere` - convert `csrrs x0, csrreg, rs` to `csrs csrreg, rs` - convert `fscsr x0, rs` to `fscsr rs` And simplify zero offsets to simply 0. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-21 21:36:55 -05:00
li t0, MSTATUS_FS_INIT
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#ifdef CONFIG_RISCV_S_MODE_EXTERNAL_SBI
csrs sstatus, t0
#else
riscv: use simplest asm expression when possible Let's take advantage of assembler pseudoinstructions: - convert `addi rd, rs, 0` to `mv rd, rs` - convert `jal x0, somewhere` to `j somewhere` - convert `csrrs x0, csrreg, rs` to `csrs csrreg, rs` - convert `fscsr x0, rs` to `fscsr rs` And simplify zero offsets to simply 0. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-21 21:36:55 -05:00
csrs mstatus, t0
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#endif /* CONFIG_RISCV_S_MODE_EXTERNAL_SBI */
riscv: Add support for floating point This change adds full shared floating point support for the RISCV architecture with minimal impact on threads with floating point support not enabled. Signed-off-by: Corey Wharton <coreyw7@fb.com>
2020-03-11 18:15:29 -07:00
/*
* Floating-point rounding mode set to IEEE-754 default, and clear
* all exception flags.
*/
riscv: use simplest asm expression when possible Let's take advantage of assembler pseudoinstructions: - convert `addi rd, rs, 0` to `mv rd, rs` - convert `jal x0, somewhere` to `j somewhere` - convert `csrrs x0, csrreg, rs` to `csrs csrreg, rs` - convert `fscsr x0, rs` to `fscsr rs` And simplify zero offsets to simply 0. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-21 21:36:55 -05:00
fscsr zero
riscv: Add support for floating point This change adds full shared floating point support for the RISCV architecture with minimal impact on threads with floating point support not enabled. Signed-off-by: Corey Wharton <coreyw7@fb.com>
2020-03-11 18:15:29 -07:00
#endif
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
#ifdef CONFIG_INIT_STACKS
kernel: interrupt/idle stacks/threads as array The set of interrupt stacks is now expressed as an array. We also define the idle threads and their associated stacks this way. This allows for iteration in cases where we have multiple CPUs. There is now a centralized declaration in kernel_internal.h. On uniprocessor systems, z_interrupt_stacks has one element and can be used in the same way as _interrupt_stack. The IRQ stack for CPU 0 is now set in init.c instead of in arch code. The extern definition of the main thread stack is now removed, this doesn't need to be in a header. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-03-12 15:37:29 -07:00
/* Pre-populate all bytes in z_interrupt_stacks with 0xAA */
la t0, z_interrupt_stacks
arch: riscv: fill all IRQ stacks with 0xAA Fill the memory of all CPU's IRQ stack with 0xAA on init, so that `z_stack_space_get` can calculate the remaining space correctly. Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-09-10 19:04:32 +08:00
/* Total size of all cores' IRQ stack */
li t1, __z_interrupt_all_stacks_SIZEOF
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
add t1, t1, t0
kernel: interrupt/idle stacks/threads as array The set of interrupt stacks is now expressed as an array. We also define the idle threads and their associated stacks this way. This allows for iteration in cases where we have multiple CPUs. There is now a centralized declaration in kernel_internal.h. On uniprocessor systems, z_interrupt_stacks has one element and can be used in the same way as _interrupt_stack. The IRQ stack for CPU 0 is now set in init.c instead of in arch code. The extern definition of the main thread stack is now removed, this doesn't need to be in a header. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-03-12 15:37:29 -07:00
/* Populate z_interrupt_stacks with 0xaaaaaaaa */
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
li t2, 0xaaaaaaaa
aa_loop:
sw t2, 0x00(t0)
addi t0, t0, 4
blt t0, t1, aa_loop
arch: riscv: fill all IRQ stacks with 0xAA Fill the memory of all CPU's IRQ stack with 0xAA on init, so that `z_stack_space_get` can calculate the remaining space correctly. Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-09-10 19:04:32 +08:00
#endif /* CONFIG_INIT_STACKS */
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
/*
* Initially, setup stack pointer to
riscv: fix crash resulting from touching the initial stack's guard area The interrupt stack is used as the system stack during kernel initialization while IRQs are not yet enabled. The sp register is set to z_interrupt_stacks + CONFIG_ISR_STACK_SIZE. CONFIG_ISR_STACK_SIZE only represents the desired usable stack size. This does not take into account the added guard area. Result is a stack whose pointer is much closer to the trigger zone than expected when CONFIG_PMP_STACK_GUARD=y, and the SMP configuration in particular pushes it over the edge during many CI test cases. Worse: during early init we're not quite ready to handle exceptions yet and complete havoc ensues with no meaningful debugging output. Make sure the early assembly code locates the actual top of the stack by generating a constant with its true size. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-09-26 22:58:21 -04:00
* z_interrupt_stacks + __z_interrupt_stack_SIZEOF
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
*/
kernel: interrupt/idle stacks/threads as array The set of interrupt stacks is now expressed as an array. We also define the idle threads and their associated stacks this way. This allows for iteration in cases where we have multiple CPUs. There is now a centralized declaration in kernel_internal.h. On uniprocessor systems, z_interrupt_stacks has one element and can be used in the same way as _interrupt_stack. The IRQ stack for CPU 0 is now set in init.c instead of in arch code. The extern definition of the main thread stack is now removed, this doesn't need to be in a header. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-03-12 15:37:29 -07:00
la sp, z_interrupt_stacks
riscv: fix crash resulting from touching the initial stack's guard area The interrupt stack is used as the system stack during kernel initialization while IRQs are not yet enabled. The sp register is set to z_interrupt_stacks + CONFIG_ISR_STACK_SIZE. CONFIG_ISR_STACK_SIZE only represents the desired usable stack size. This does not take into account the added guard area. Result is a stack whose pointer is much closer to the trigger zone than expected when CONFIG_PMP_STACK_GUARD=y, and the SMP configuration in particular pushes it over the edge during many CI test cases. Worse: during early init we're not quite ready to handle exceptions yet and complete havoc ensues with no meaningful debugging output. Make sure the early assembly code locates the actual top of the stack by generating a constant with its true size. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-09-26 22:58:21 -04:00
li t0, __z_interrupt_stack_SIZEOF
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
add sp, sp, t0
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
#ifdef CONFIG_THREAD_LOCAL_STORAGE
arch/riscv: fix early TLS setup and save callee-saved registers Fix the early TLS initialization sequence on RISC-V to correctly set up the thread pointer (tp) before any C code runs, and save/restore callee-saved registers as required by the ABI. Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
2026-04-01 15:02:05 -07:00
/*
arch: riscv: address review nits on TLS canary patches Add copyright year, reflow comments, remote duplicate __tls_end, and remove commented-out code. Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
2026-04-20 14:54:21 -07:00
* Initialize TLS before the first C function call. The compiler inserts
* stack canary checks into C functions, and the canary value is read from
* a TLS variable via tp. Without this early init, tp is not set up and
* any C function called during early boot (e.g. z_prep_c) would read the
* canary from an arbitrary memory location.
arch/riscv: fix early TLS setup and save callee-saved registers Fix the early TLS initialization sequence on RISC-V to correctly set up the thread pointer (tp) before any C code runs, and save/restore callee-saved registers as required by the ABI. Signed-off-by: Mayur Salve <msalve@qti.qualcomm.com>
2026-04-01 15:02:05 -07:00
*/
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
riscv_tls_init_early
#endif
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#if defined(CONFIG_RISCV_SMRNMI_ENABLE_NMI_DELIVERY) && !defined(CONFIG_RISCV_S_MODE_EXTERNAL_SBI)
arch/riscv: Enable NMI delivery for SMRNMI hardware Add option to enable NMI delivery on boot for SMRNMI hardware. Changes: - Add CONFIG_RISCV_SMRNMI_ENABLE_NMI_DELIVERY Kconfig option - Define SMRNMI CSRs in arch/riscv/include/csr.h - Set NMIE bit during boot to enable NMI delivery SMRNMI hardware generates but doesn't deliver NMIs when NMIE=0 (default). This causes twister test failures and prevents handling of critical hardware events like watchdog NMIs and ECC errors. Setting NMIE=1 enables NMI delivery, but note that this implementation only sets the enable bit - it does not provide full SMRNMI support (no mnret instruction handling, no RNMI handlers). Users must implement proper RNMI handlers in SoC-specific code to avoid undefined behavior. Signed-off-by: Afonso Oliveira <afonsoo@synopsys.com>
2025-07-28 19:51:48 +01:00
csrs CSR_MNSTATUS, MNSTATUS_NMIE
#endif
arch: riscv32: support CONFIG_WDOG_INIT Borrow from an Arm Cortex-M convention where each Kconfig.soc can define a 'config WDOG_INIT' that does watchdog initialization early in the boot process if that SoC needs it. Some SoCs have watchdogs that are enabled by default and need to be turned off during reset handling (to be re-enabled if necessary by a Zephyr watchdog driver). Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-11-13 14:37:41 -07:00
#ifdef CONFIG_WDOG_INIT
call _WdogInit
#endif
arch: riscv: add Supervisor-mode (S-mode) support Introduce CONFIG_RISCV_S_MODE to select Supervisor-mode execution. Add depends on !RISCV_S_MODE to RISCV_PMP since PMP CSRs are inaccessible from S-mode. Add an M-mode SBI shim (reset.S + sbi.S) that configures exception delegation, PMP, and counter access before dropping to S-mode via mret. The shim handles SBI_SET_TIMER ecalls from S-mode and forwards MTIP to STIP so the supervisor timer driver works without a full SBI firmware. Introduce privilege-level abstractions in isr.S (RV_CAUSE, RV_EPC, RV_STATUS, RV_TVAL, etc.) and update all runtime code that previously accessed M-mode-only CSRs (mcause, mtval, mstatus, mie, mip) to use the S-mode equivalents when CONFIG_RISCV_S_MODE is set. ARCH_EXCEPT in kernel context uses ebreak (cause=3, Breakpoint) instead of a direct z_riscv_fatal_error() call. In S-mode, ecall (cause=9) is kept in M-mode for SBI and never reaches the S-mode exception handler; a direct call with NULL esf caused the stack unwinder to crash into an infinite fault loop. ebreak is delegated to S-mode by our medeleg configuration; isr.S treats ebreak with t0=RV_ECALL_RUNTIME_EXCEPT the same way M-mode treats ecall-based ARCH_EXCEPT. Signed-off-by: Alexios Lyrakis <alexios.lyrakis@gmail.com>
2026-03-28 15:34:55 +00:00
#ifdef CONFIG_RISCV_S_MODE
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#ifdef CONFIG_RISCV_S_MODE_INTERNAL_SBI
arch: riscv: add Supervisor-mode (S-mode) support Introduce CONFIG_RISCV_S_MODE to select Supervisor-mode execution. Add depends on !RISCV_S_MODE to RISCV_PMP since PMP CSRs are inaccessible from S-mode. Add an M-mode SBI shim (reset.S + sbi.S) that configures exception delegation, PMP, and counter access before dropping to S-mode via mret. The shim handles SBI_SET_TIMER ecalls from S-mode and forwards MTIP to STIP so the supervisor timer driver works without a full SBI firmware. Introduce privilege-level abstractions in isr.S (RV_CAUSE, RV_EPC, RV_STATUS, RV_TVAL, etc.) and update all runtime code that previously accessed M-mode-only CSRs (mcause, mtval, mstatus, mie, mip) to use the S-mode equivalents when CONFIG_RISCV_S_MODE is set. ARCH_EXCEPT in kernel context uses ebreak (cause=3, Breakpoint) instead of a direct z_riscv_fatal_error() call. In S-mode, ecall (cause=9) is kept in M-mode for SBI and never reaches the S-mode exception handler; a direct call with NULL esf caused the stack unwinder to crash into an infinite fault loop. ebreak is delegated to S-mode by our medeleg configuration; isr.S treats ebreak with t0=RV_ECALL_RUNTIME_EXCEPT the same way M-mode treats ecall-based ARCH_EXCEPT. Signed-off-by: Alexios Lyrakis <alexios.lyrakis@gmail.com>
2026-03-28 15:34:55 +00:00
/* Set M-mode trap vector to our SBI handler */
la t0, __m_mode_sbi_handler
csrw mtvec, t0
/* Delegate all exceptions to S-mode except S-mode ecall and
* M-mode ecall, which stay in M-mode to be handled by our SBI.
*/
li t0, ~((1 << RISCV_EXC_ECALLS) | (1 << RISCV_EXC_ECALLM))
csrw medeleg, t0
/* Delegate supervisor software, timer and external interrupts
* to S-mode.
*/
li t0, (MIP_SSIP | MIP_STIP | MIP_SEIP)
csrw mideleg, t0
/* PMP entry 0: NAPOT, RWX, covers all memory so S-mode can
* access everything
*/
li t0, -1
csrw pmpaddr0, t0
li t0, (PMP_NAPOT | PMP_R | PMP_W | PMP_X)
csrw pmpcfg0, t0
/* Initialize mscratch to M-mode stack top */
la t0, m_mode_stack_top
csrw mscratch, t0
/* Allow S-mode to read cycle, time and instret counters */
li t0, (MCOUNTEREN_CY | MCOUNTEREN_TM | MCOUNTEREN_IR)
csrw mcounteren, t0
/* Enable M-mode timer interrupt so MTIP fires and is forwarded to S-mode as STIP */
li t0, MIP_MTIP
csrs mie, t0
/* Set MPP=S-mode in mstatus then mret into S-mode */
li t0, MSTATUS_MPP
csrc mstatus, t0
li t0, MSTATUS_MPP_S
csrs mstatus, t0
la t0, s_mode_entry
csrw mepc, t0
mret
arch: riscv: Add S-mode only support - When launching Zephyr from a bootloader (eg: u-boot), the image binary launches in S-mode. Thus we cannot call M-mode only functions, or perform M to S mode transition. - SMP is currently broken in this setup. MPU, FPU not tested yet either since PolarFire soc does not enable it by default. - Tested on beaglev_fire with PolarFire soc. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
2026-07-15 21:32:14 +05:30
#endif /* CONFIG_RISCV_S_MODE_INTERNAL_SBI */
arch: riscv: add Supervisor-mode (S-mode) support Introduce CONFIG_RISCV_S_MODE to select Supervisor-mode execution. Add depends on !RISCV_S_MODE to RISCV_PMP since PMP CSRs are inaccessible from S-mode. Add an M-mode SBI shim (reset.S + sbi.S) that configures exception delegation, PMP, and counter access before dropping to S-mode via mret. The shim handles SBI_SET_TIMER ecalls from S-mode and forwards MTIP to STIP so the supervisor timer driver works without a full SBI firmware. Introduce privilege-level abstractions in isr.S (RV_CAUSE, RV_EPC, RV_STATUS, RV_TVAL, etc.) and update all runtime code that previously accessed M-mode-only CSRs (mcause, mtval, mstatus, mie, mip) to use the S-mode equivalents when CONFIG_RISCV_S_MODE is set. ARCH_EXCEPT in kernel context uses ebreak (cause=3, Breakpoint) instead of a direct z_riscv_fatal_error() call. In S-mode, ecall (cause=9) is kept in M-mode for SBI and never reaches the S-mode exception handler; a direct call with NULL esf caused the stack unwinder to crash into an infinite fault loop. ebreak is delegated to S-mode by our medeleg configuration; isr.S treats ebreak with t0=RV_ECALL_RUNTIME_EXCEPT the same way M-mode treats ecall-based ARCH_EXCEPT. Signed-off-by: Alexios Lyrakis <alexios.lyrakis@gmail.com>
2026-03-28 15:34:55 +00:00
s_mode_entry:
#endif /* CONFIG_RISCV_S_MODE */
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
/*
arch: _PrepC -> z_prep_c Rename to use common naming for z_prep_c applied to all architectures. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2023-12-08 07:55:21 -05:00
* Jump into C domain. z_prep_c zeroes BSS, copies rw data into RAM,
all: Update reserved function names Update reserved function names starting with one underscore, replacing them as follows: '_k_' with 'z_' '_K_' with 'Z_' '_handler_' with 'z_handl_' '_Cstart' with 'z_cstart' '_Swap' with 'z_swap' This renaming is done on both global and those static function names in kernel/include and include/. Other static function names in kernel/ are renamed by removing the leading underscore. Other function names not starting with any prefix listed above are renamed starting with a 'z_' or 'Z_' prefix. Function names starting with two or three leading underscores are not automatcally renamed since these names will collide with the variants with two or three leading underscores. Various generator scripts have also been updated as well as perf, linker and usb files. These are drivers/serial/uart_handlers.c include/linker/kobject-text.ld kernel/include/syscall_handler.h scripts/gen_kobject_list.py scripts/gen_syscall_header.py Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
2019-03-08 14:19:05 -07:00
* and then enters kernel z_cstart
arch: added support for the riscv32 architecture RISC-V is an open-source instruction set architecture. Added support for the 32bit version of RISC-V to Zephyr. 1) exceptions/interrupts/faults are handled at the architecture level via the __irq_wrapper handler. Context saving/restoring of registers can be handled at both architecture and SOC levels. If SOC-specific registers need to be saved, SOC level needs to provide __soc_save_context and __soc_restore_context functions that shall be accounted by the architecture level, when corresponding config variable RISCV_SOC_CONTEXT_SAVE is set. 2) As RISC-V architecture does not provide a clear ISA specification about interrupt handling, each RISC-V SOC handles it in its own way. Hence, at the architecture level, the __irq_wrapper handler expects the following functions to be provided by the SOC level: __soc_is_irq: to check if the exception is the result of an interrupt or not. __soc_handle_irq: handle pending IRQ at SOC level (ex: clear pending IRQ in SOC-specific IRQ register) 3) Thread/task scheduling, as well as IRQ offloading are handled via the RISC-V system call ("ecall"), which is also handled via the __irq_wrapper handler. The _Swap asm function just calls "ecall" to generate an exception. 4) As there is no conventional way of handling CPU power save in RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle functions just unlock interrupts and return to the caller, without issuing any CPU power saving instruction. Nonetheless, to allow SOC-level to implement proper CPU power save, nano_cpu_idle and nano_cpu_atomic_idle functions are defined as __weak at the architecture level. Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389 Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
*/
arch: _PrepC -> z_prep_c Rename to use common naming for z_prep_c applied to all architectures. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2023-12-08 07:55:21 -05:00
call z_prep_c
arch/riscv: Boot secondary CPUs for SMP support Secondary CPUs are now initialised and made available to the system. If the system has more CPUs than configured via CONFIG_MP_NUM_CPUS, those are still left looping as before. Some implementations of `soc_interrupt_init` also changed to use `arch_irq_lock` instead of `irq_lock`. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2021-12-29 10:22:48 -08:00
boot_secondary_core:
riscv: don't include the secondary CPU boot code when not needed Linker garbage collection couldn't work due to the explicit reference in reset.S. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-01-06 22:33:35 -05:00
#if CONFIG_MP_MAX_NUM_CPUS > 1
arch: riscv: fix hangup of multicore boot This patch fixes hangup of RISC-V multicore boot. Currently boot sequence uses a riscv_cpu_wake_flag to notify wakeup request for secondary core(s). But initial value of riscv_cpu_wake_flag is undefined, so current mechanism is going to hangup if riscv_cpu_wake_flag and mhartid of secondary core have the same value. This is an example situation of this problem: - hart1: check riscv_cpu_wake_flag (value is 1) and end the loop - hart1: set riscv_cpu_wake_flag to 0 - hart0: set riscv_cpu_wake_flag to 1 hart0 expects it will be changed to 0 by hart1 but it has never happened Note: - hart0's mhartid is 0, hart1's mhartid is 1 - hart0 is main, hart1 is secondary in this example Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
2023-11-09 13:50:31 +09:00
la t0, riscv_cpu_wake_flag
li t1, -1
sr t1, 0(t0)
la t0, riscv_cpu_boot_flag
sr zero, 0(t0)
wait_secondary_wake_flag:
arch/riscv: Boot secondary CPUs for SMP support Secondary CPUs are now initialised and made available to the system. If the system has more CPUs than configured via CONFIG_MP_NUM_CPUS, those are still left looping as before. Some implementations of `soc_interrupt_init` also changed to use `arch_irq_lock` instead of `irq_lock`. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2021-12-29 10:22:48 -08:00
la t0, riscv_cpu_wake_flag
riscv: better abstraction for register-wide load/store opcodes Those are prominent enough that having RV_OP_LOADREG and RV_OP_STOREREG shouting at you all over the place is rather unpleasant and bad taste. Let's create pseudo-instructions of our own with assembler macros rather than preprocessor defines and only in assembly scope. This makes the asm code way more uniform and readable. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-22 14:09:55 -05:00
lr t0, 0(t0)
arch: riscv: fix hangup of multicore boot This patch fixes hangup of RISC-V multicore boot. Currently boot sequence uses a riscv_cpu_wake_flag to notify wakeup request for secondary core(s). But initial value of riscv_cpu_wake_flag is undefined, so current mechanism is going to hangup if riscv_cpu_wake_flag and mhartid of secondary core have the same value. This is an example situation of this problem: - hart1: check riscv_cpu_wake_flag (value is 1) and end the loop - hart1: set riscv_cpu_wake_flag to 0 - hart0: set riscv_cpu_wake_flag to 1 hart0 expects it will be changed to 0 by hart1 but it has never happened Note: - hart0's mhartid is 0, hart1's mhartid is 1 - hart0 is main, hart1 is secondary in this example Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
2023-11-09 13:50:31 +09:00
bne a0, t0, wait_secondary_wake_flag
arch/riscv: Boot secondary CPUs for SMP support Secondary CPUs are now initialised and made available to the system. If the system has more CPUs than configured via CONFIG_MP_NUM_CPUS, those are still left looping as before. Some implementations of `soc_interrupt_init` also changed to use `arch_irq_lock` instead of `irq_lock`. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2021-12-29 10:22:48 -08:00
/* Set up stack */
la t0, riscv_cpu_sp
riscv: better abstraction for register-wide load/store opcodes Those are prominent enough that having RV_OP_LOADREG and RV_OP_STOREREG shouting at you all over the place is rather unpleasant and bad taste. Let's create pseudo-instructions of our own with assembler macros rather than preprocessor defines and only in assembly scope. This makes the asm code way more uniform and readable. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-22 14:09:55 -05:00
lr sp, 0(t0)
arch/riscv: Boot secondary CPUs for SMP support Secondary CPUs are now initialised and made available to the system. If the system has more CPUs than configured via CONFIG_MP_NUM_CPUS, those are still left looping as before. Some implementations of `soc_interrupt_init` also changed to use `arch_irq_lock` instead of `irq_lock`. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2021-12-29 10:22:48 -08:00
arch: riscv: use TLS-based stack canary guard 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>
2026-03-16 17:53:53 -07:00
#ifdef CONFIG_THREAD_LOCAL_STORAGE
/* Initialize tp early so TLS-based stack canaries work on secondary CPUs */
mv s2, a0 /* save hartid across TLS init calls */
riscv_tls_init_early
mv a0, s2 /* restore hartid */
#endif
arch: riscv: fix hangup of multicore boot This patch fixes hangup of RISC-V multicore boot. Currently boot sequence uses a riscv_cpu_wake_flag to notify wakeup request for secondary core(s). But initial value of riscv_cpu_wake_flag is undefined, so current mechanism is going to hangup if riscv_cpu_wake_flag and mhartid of secondary core have the same value. This is an example situation of this problem: - hart1: check riscv_cpu_wake_flag (value is 1) and end the loop - hart1: set riscv_cpu_wake_flag to 0 - hart0: set riscv_cpu_wake_flag to 1 hart0 expects it will be changed to 0 by hart1 but it has never happened Note: - hart0's mhartid is 0, hart1's mhartid is 1 - hart0 is main, hart1 is secondary in this example Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
2023-11-09 13:50:31 +09:00
la t0, riscv_cpu_boot_flag
li t1, 1
sr t1, 0(t0)
arch: introduce arch_secondary_cpu_init Different architecture are doing this in custom ways and using different naming conventions, unify this interface and make it part of the arch implementation for SMP. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2023-12-13 15:27:41 -05:00
j arch_secondary_cpu_init
riscv: don't include the secondary CPU boot code when not needed Linker garbage collection couldn't work due to the explicit reference in reset.S. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-01-06 22:33:35 -05:00
#else
j loop_unconfigured_cores
#endif
riscv: enable booting from non-zero indexed RISC-V hart RISC-V multi-hart systems that employ a heterogeneous core complex are not guaranteed to have the smp capable harts starting with a unique id of zero, matching Zephyr's sequential zero indexed cpu numbering scheme. Add option, RV_BOOT_HART to choose the hart to boot from. On reset, check the current hart equals RV_BOOT_HART: if so, boot first core. else, loop in the boot secondary core and wait to be brought up. For multi-hart systems that are not running a Zephyr mp or smp application, park the non zephyr related harts in a wfi loop. Signed-off-by: Conor Paxton <conor.paxton@microchip.com>
2023-01-16 13:53:06 +00:00
loop_unconfigured_cores:
wfi
j loop_unconfigured_cores
Copy permalink