michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/arch/riscv/Kconfig

470 lines
15 KiB
Text
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>
arch: riscv: add Kconfig option for imprecise FPU state tracking According to the RISC-V Instruction Set Manual: Volume II, Version 20240411 (Section 3.1.6.6), some implementations may choose to track the dirtiness of the floating-point register state imprecisely by reporting the state to be dirty even when it has not been modified. This option reflects that. Also add a filter in `tests/arch/riscv/fpu_sharing/` based on imprecise FPU state tracking Signed-off-by: Jakub Wasilewski <jwasilewski@internships.antmicro.com> Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
2024-07-09 13:25:46 +02:00
# Copyright (c) 2024 Antmicro <www.antmicro.com>
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
riscv32: rename to riscv With the upcoming riscv64 support, it is best to use "riscv" as the subdirectory name and common symbols as riscv32 and riscv64 support code is almost identical. Then later decide whether 32-bit or 64-bit compilation is wanted. Redirects for the web documentation are also included. Then zephyrbot complained about this: " New files added that are not covered in CODEOWNERS: dts/riscv/microsemi-miv.dtsi dts/riscv/riscv32-fe310.dtsi Please add one or more entries in the CODEOWNERS file to cover those files " So I assigned them to those who created them. Feel free to readjust as necessary. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-17 13:17:05 -04:00
menu "RISCV Options"
depends on RISCV
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
config ARCH
string
arch: riscv: always use 'riscv' for CONFIG_ARCH Because the riscv32/riscv64 is redundant, one can get the same information combining CONFIG_ARCH + CONFIG_64BIT. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-02-07 11:23:28 +01:00
default "riscv"
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
riscv: Set mabi and march flags for floating point Adds handling of the FLOAT_64BIT option when determining the ISA flags as well as introduces a new Kconfig option to enable/disable the hard-float calling convention. Signed-off-by: Corey Wharton <coreyw7@fb.com>
2020-04-07 15:24:36 -07:00
config FLOAT_HARD
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "Hard-float calling convention"
riscv: Set mabi and march flags for floating point Adds handling of the FLOAT_64BIT option when determining the ISA flags as well as introduces a new Kconfig option to enable/disable the hard-float calling convention. Signed-off-by: Corey Wharton <coreyw7@fb.com>
2020-04-07 15:24:36 -07:00
default y
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
depends on FPU
riscv: Set mabi and march flags for floating point Adds handling of the FLOAT_64BIT option when determining the ISA flags as well as introduces a new Kconfig option to enable/disable the hard-float calling convention. Signed-off-by: Corey Wharton <coreyw7@fb.com>
2020-04-07 15:24:36 -07:00
help
This option enables the hard-float calling convention.
arch: riscv: introduce `CONFIG_RISCV_GP_PURPOSE` choice Introduce `CONFIG_RISCV_GP_PURPOSE` choice to make sure that only one of `CONFIG_RISCV_GP` or `CONFIG_RISCV_CURRENT_VIA_GP` can be enabled, instead of relying of dependencies. To do that, introduce a new `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING` that can be selected by SoC when it implemented global pointer (GP) initialization for relative addressing in its linker. `CONFIG_RISCV_GP` will be the default choice when `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING=y` Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-11-25 12:54:01 +08:00
choice RISCV_GP_PURPOSE
prompt "Purpose of the global pointer (GP) register"
default RISCV_GP if RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING
arch: riscv: introduce global pointer relative addressing support Enable RISC-V GP relative addressing by linker relaxation to reduce the code size. It optimizes addressing of globals in small data section (.sdata). The gp initialization at program start needs each SoC support. Also, if RISC-V SoC has custom linker script, SoC should provide __global_pointer$ symbol in it's linker script. Signed-off-by: Jim Shu <cwshu@andestech.com>
2021-08-17 02:38:33 +08:00
config RISCV_GP
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "RISC-V global pointer relative addressing"
arch: riscv: introduce `CONFIG_RISCV_GP_PURPOSE` choice Introduce `CONFIG_RISCV_GP_PURPOSE` choice to make sure that only one of `CONFIG_RISCV_GP` or `CONFIG_RISCV_CURRENT_VIA_GP` can be enabled, instead of relying of dependencies. To do that, introduce a new `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING` that can be selected by SoC when it implemented global pointer (GP) initialization for relative addressing in its linker. `CONFIG_RISCV_GP` will be the default choice when `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING=y` Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-11-25 12:54:01 +08:00
depends on RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING
arch: riscv: introduce global pointer relative addressing support Enable RISC-V GP relative addressing by linker relaxation to reduce the code size. It optimizes addressing of globals in small data section (.sdata). The gp initialization at program start needs each SoC support. Also, if RISC-V SoC has custom linker script, SoC should provide __global_pointer$ symbol in it's linker script. Signed-off-by: Jim Shu <cwshu@andestech.com>
2021-08-17 02:38:33 +08:00
help
Use global pointer relative addressing for small globals declared
anywhere in the executable. It can benefit performance and reduce
the code size.
Note: To support this feature, RISC-V SoC needs to initialize
global pointer at program start or earlier than any instruction
using GP relative addressing.
arch: riscv: implement ARCH_HAS_CUSTOM_CURRENT_IMPL with GP Implement `arch_curr_thread()` & `arch_set_curr_thread()` with the global pointer (GP) register. Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-11-01 12:12:41 +08:00
config RISCV_CURRENT_VIA_GP
bool "Store current thread into the global pointer (GP) register"
depends on MP_MAX_NUM_CPUS > 1
select ARCH_HAS_CUSTOM_CURRENT_IMPL
help
Store the current thread's pointer into the global pointer (GP) register.
Revert "arch: deprecate `_current`" Mostly a revert of commit b1def7145fd1 ("arch: deprecate `_current`"). This commit was part of PR #80716 whose initial purpose was about providing an architecture specific optimization for _current. The actual deprecation was sneaked in later on without proper discussion. The Zephyr core always used _current before and that was fine. It is quite prevalent as well and the alternative is proving rather verbose. Furthermore, as a concept, the "current thread" is not something that is necessarily architecture specific. Therefore the primary abstraction should not carry the arch_ prefix. Hence this revert. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2025-01-07 12:00:43 -05:00
When is enabled, calls to `_current` & `k_sched_current_thread_query()` will
arch: riscv: implement ARCH_HAS_CUSTOM_CURRENT_IMPL with GP Implement `arch_curr_thread()` & `arch_set_curr_thread()` with the global pointer (GP) register. Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-11-01 12:12:41 +08:00
be reduced to a single register read.
arch: riscv: introduce `CONFIG_RISCV_GP_PURPOSE` choice Introduce `CONFIG_RISCV_GP_PURPOSE` choice to make sure that only one of `CONFIG_RISCV_GP` or `CONFIG_RISCV_CURRENT_VIA_GP` can be enabled, instead of relying of dependencies. To do that, introduce a new `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING` that can be selected by SoC when it implemented global pointer (GP) initialization for relative addressing in its linker. `CONFIG_RISCV_GP` will be the default choice when `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING=y` Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-11-25 12:54:01 +08:00
endchoice # RISCV_GP_PURPOSE
riscv: Introduce RISCV_ALWAYS_SWITCH_THROUGH_ECALL Some early RISC-V SoCs have a problem when an `mret` instruction is used outside a trap handler. After the latest Zephyr RISC-V huge rework, the arch_switch code is indeed calling `mret` when not in handler mode, breaking some early RISC-V platforms. Optionally restore the old behavior by adding a new CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL symbol. Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-06-30 14:40:52 +02:00
config RISCV_ALWAYS_SWITCH_THROUGH_ECALL
bool "Do not use mret outside a trap handler context"
riscv: exclude more code when multithreading is disabled This will avoid unconditionally pulling z_riscv_switch() into the build as it is not used, reducing the resulting binary some more. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-05-30 16:30:56 -04:00
depends on MULTITHREADING
riscv: Introduce RISCV_ALWAYS_SWITCH_THROUGH_ECALL Some early RISC-V SoCs have a problem when an `mret` instruction is used outside a trap handler. After the latest Zephyr RISC-V huge rework, the arch_switch code is indeed calling `mret` when not in handler mode, breaking some early RISC-V platforms. Optionally restore the old behavior by adding a new CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL symbol. Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-06-30 14:40:52 +02:00
help
Use mret instruction only when in a trap handler.
This is for RISC-V implementations that require every mret to be
balanced with an ecall. This is not required by the RISC-V spec
and most people should say n here to minimize context switching
overhead.
arch: riscv: smp: allow other IPI implementation The currently IPI implementation assumes that CLINT exists in the system, however, that might not be the case as IPI can be implemented with PLIC that supports software-triggering as well, such as the Andes NCEPLIC100. Refactor the CLINT-based IPI implementations into `ipi_clint.c`, and create Kconfig that selects the CLINT implementation when `sifive-clint0` exists and enabled, otherwise default to `RISCV_SMP_IPI_CUSTOM` which allows OOT implementation. This also makes way for the upstreaming of non-clint IPI implementation later. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-11-12 13:15:24 +08:00
choice RISCV_SMP_IPI_IMPL
prompt "RISC-V SMP IPI implementation"
depends on SMP
default RISCV_SMP_IPI_CLINT if DT_HAS_SIFIVE_CLINT0_ENABLED
default RISCV_SMP_IPI_CUSTOM
config RISCV_SMP_IPI_CLINT
bool "CLINT-based IPI"
depends on DT_HAS_SIFIVE_CLINT0_ENABLED
help
Use CLINT-based IPI implementation.
config RISCV_SMP_IPI_CUSTOM
bool "Custom IPI implementation"
help
Allow custom IPI implementation.
When this is selected, the following functions must be provided:
- arch_sched_directed_ipi()
- arch_flush_fpu_ipi() if CONFIG_FPU_SHARING
- arch_spin_relax() if CONFIG_FPU_SHARING
- arch_smp_init()
endchoice # RISCV_SMP_IPI_IMPL
riscv32: rename to riscv With the upcoming riscv64 support, it is best to use "riscv" as the subdirectory name and common symbols as riscv32 and riscv64 support code is almost identical. Then later decide whether 32-bit or 64-bit compilation is wanted. Redirects for the web documentation are also included. Then zephyrbot complained about this: " New files added that are not covered in CODEOWNERS: dts/riscv/microsemi-miv.dtsi dts/riscv/riscv32-fe310.dtsi Please add one or more entries in the CODEOWNERS file to cover those files " So I assigned them to those who created them. Feel free to readjust as necessary. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-17 13:17:05 -04:00
menu "RISCV Processor Options"
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
config INCLUDE_RESET_VECTOR
arch: riscv: update the description of INCLUDE_RESET_VECTOR Kconfig Update the description of the `INCLUDE_RESET_VECTOR` Kconfig so that it is more clear to the user what it does. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-06-28 14:02:27 +08:00
bool "Jumps to __initialize directly"
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
help
arch: riscv: update the description of INCLUDE_RESET_VECTOR Kconfig Update the description of the `INCLUDE_RESET_VECTOR` Kconfig so that it is more clear to the user what it does. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-06-28 14:02:27 +08:00
Select 'y' here to use the Zephyr provided default implementation that
jumps to `__initialize` directly. Otherwise a SOC needs to provide its
custom `__reset` routine.
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: introduce RISCV_PRIVILEGED Introduce a new arch level Kconfig option to signal the implementation of the RISCV Privileged ISA spec. This replaces SOC_FAMILY_RISCV_PRIVILEGED, because this is not a SoC specific property, nor a SoC family. Note that the SoC family naming scheme will be fixed in upcoming commits. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-01-03 12:39:36 +01:00
config RISCV_PRIVILEGED
bool
select ARCH_HAS_RAMFUNC_SUPPORT if XIP
help
Option selected by SoCs implementing the RISC-V privileged ISA.
riscv: Add support for hardware stacking / unstacking Some RISC-V SoCs implement a mechanism for hardware supported stacking / unstacking of registers during ISR / exceptions. What happens is that on ISR / exception entry part of the context is automatically saved by the hardware on the stack without software intervention, and the same part of the context is restored by the hardware usually on mret. This is currently not yet supported by Zephyr, where the full context must be saved by software in the full fledged ESF. This patcheset is trying to address exactly this case. At least three things are needed to support in a general fashion this problem: (1) a way to store in software only the part of the ESF not already stacked by hardware, (2) a way to restore in software only the part of the context that is not going to be restored by hardware and (3) a way to define a custom ESF. Point (3) is important because the full ESF frame is now composed by a custom part depending on the hardware (that can choose which register to stack / unstack and the order they are saved onto the stack) and a part defined in software for the remaining part of the context. In this patch a new CONFIG_RISCV_SOC_HAS_ISR_STACKING is introduced that enables the code path supporting the three points by the mean of three macros that must be implemented by the user in a soc_stacking.h file: SOC_ISR_SW_STACKING, SOC_ISR_SW_UNSTACKING and SOC_ISR_STACKING_ESF (refer to the symbol help for more details). This is an example of soc_isr_stacking.h for an hardware that doesn't do any hardware stacking / unstacking but everything is managed in software: #ifndef __SOC_ISR_STACKING #define __SOC_ISR_STACKING #if !defined(_ASMLANGUAGE) #define SOC_ISR_STACKING_ESF_DECLARE \ struct __esf { \ unsigned long ra; \ unsigned long t0; \ unsigned long t1; \ unsigned long t2; \ unsigned long t3; \ unsigned long t4; \ unsigned long t5; \ unsigned long t6; \ unsigned long a0; \ unsigned long a1; \ unsigned long a2; \ unsigned long a3; \ unsigned long a4; \ unsigned long a5; \ unsigned long a6; \ unsigned long a7; \ unsigned long mepc; \ unsigned long mstatus; \ unsigned long s0; \ } __aligned(16) #else #define SOC_ISR_SW_STACKING \ addi sp, sp, -__z_arch_esf_t_SIZEOF; \ DO_CALLER_SAVED(sr); #define SOC_ISR_SW_UNSTACKING \ DO_CALLER_SAVED(lr); #endif /* _ASMLANGUAGE */ #endif /* __SOC_ISR_STACKING */ Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-12-27 20:14:51 +01:00
config RISCV_SOC_HAS_ISR_STACKING
bool
depends on !USERSPACE
help
Enable low-level SOC-specific hardware stacking / unstacking
operations during ISR. This hidden option needs to be selected by SoC
if this feature is supported.
Some SOCs implement a mechanism for which, on interrupt handling,
part of the context is automatically saved by the hardware on the
stack according to a custom ESF format. The same part of the context
is automatically restored by hardware on mret.
Enabling this option requires that the SoC provides a
soc_isr_stacking.h header which defines the following:
- SOC_ISR_SW_STACKING: macro guarded by _ASMLANGUAGE called by the
IRQ wrapper assembly code on ISR entry to save in the ESF the
remaining part of the context not pushed already on the stack by
the hardware.
- SOC_ISR_SW_UNSTACKING: macro guarded by _ASMLANGUAGE called by the
IRQ wrapper assembly code on ISR exit to restore the part of the
context from the ESF that won't be restored by hardware on mret.
- SOC_ISR_STACKING_ESF_DECLARE: structure declaration for the ESF
guarded by !_ASMLANGUAGE. The ESF should be defined to account for
the hardware stacked registers in the proper order as they are
saved on the stack by the hardware, and the registers saved by the
arch: rename all esf struct to `struct arch_esf` Rename every architecture's esf struct to `struct esf`. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-06-01 10:26:04 +08:00
software macros. The structure must be called 'struct arch_esf'.
riscv: Add support for hardware stacking / unstacking Some RISC-V SoCs implement a mechanism for hardware supported stacking / unstacking of registers during ISR / exceptions. What happens is that on ISR / exception entry part of the context is automatically saved by the hardware on the stack without software intervention, and the same part of the context is restored by the hardware usually on mret. This is currently not yet supported by Zephyr, where the full context must be saved by software in the full fledged ESF. This patcheset is trying to address exactly this case. At least three things are needed to support in a general fashion this problem: (1) a way to store in software only the part of the ESF not already stacked by hardware, (2) a way to restore in software only the part of the context that is not going to be restored by hardware and (3) a way to define a custom ESF. Point (3) is important because the full ESF frame is now composed by a custom part depending on the hardware (that can choose which register to stack / unstack and the order they are saved onto the stack) and a part defined in software for the remaining part of the context. In this patch a new CONFIG_RISCV_SOC_HAS_ISR_STACKING is introduced that enables the code path supporting the three points by the mean of three macros that must be implemented by the user in a soc_stacking.h file: SOC_ISR_SW_STACKING, SOC_ISR_SW_UNSTACKING and SOC_ISR_STACKING_ESF (refer to the symbol help for more details). This is an example of soc_isr_stacking.h for an hardware that doesn't do any hardware stacking / unstacking but everything is managed in software: #ifndef __SOC_ISR_STACKING #define __SOC_ISR_STACKING #if !defined(_ASMLANGUAGE) #define SOC_ISR_STACKING_ESF_DECLARE \ struct __esf { \ unsigned long ra; \ unsigned long t0; \ unsigned long t1; \ unsigned long t2; \ unsigned long t3; \ unsigned long t4; \ unsigned long t5; \ unsigned long t6; \ unsigned long a0; \ unsigned long a1; \ unsigned long a2; \ unsigned long a3; \ unsigned long a4; \ unsigned long a5; \ unsigned long a6; \ unsigned long a7; \ unsigned long mepc; \ unsigned long mstatus; \ unsigned long s0; \ } __aligned(16) #else #define SOC_ISR_SW_STACKING \ addi sp, sp, -__z_arch_esf_t_SIZEOF; \ DO_CALLER_SAVED(sr); #define SOC_ISR_SW_UNSTACKING \ DO_CALLER_SAVED(lr); #endif /* _ASMLANGUAGE */ #endif /* __SOC_ISR_STACKING */ Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-12-27 20:14:51 +01:00
arch: riscv: option to init custom hw stacked esf members. When RISCV_SOC_HAS_ISR_STACKING is used, it may be needed to initialize custom hw stacked esf members. Some initial values may need to be aligned with hw stacking mechanism to avoid any side effects. Signed-off-by: Łukasz Stępnicki <lukasz.stepnicki@nordicsemi.no>
2025-01-16 09:36:08 +01:00
- SOC_ISR_STACKING_ESR_INIT: macro guarded by !_ASMLANGUAGE.
Some hardware stacked registers should be initialized on init
stack with proper values. This prevents from incorrect behavior
on entry context switch when initial stack is restored.
riscv: irq: Correct interrupt handling in clic non-vectored mode According to the clic specification (https://github.com/riscv/riscv-fast-interrupt), the mnxti register has be written, in order to clear the pending bit for non-vectored interrupts. For vectored interrupts, this is automatically done. From the spec: "If the pending interrupt is edge-triggered, hardware will automatically clear the corresponding pending bit when the CSR instruction that accesses xnxti includes a write." I added a kconfig `RISCV_SOC_HAS_CUSTOM_IRQ_HANDLING` to allow custom irq handling. If enabled, `__soc_handle_all_irqs` has to be implemented. For clic, non-vectored mode, I added a `__soc_handle_all_irqs`, that handles the pending interrupts according to the pseudo code in the spec. Signed-off-by: Greter Raffael <rgreter@baumer.com>
2023-12-21 12:41:59 +00:00
config RISCV_SOC_HAS_CUSTOM_IRQ_HANDLING
bool
help
This allows the SoC to overwrite the irq handling. If enabled, the
function __soc_handle_all_irqs has to be implemented. It shall service
and clear all pending interrupts.
riscv: Allow SOC to override arch_irq_{lock,unlock,unlocked} RISC-V has a modular design. Some hardware with a custom interrupt controller needs a bit more work to lock / unlock IRQs. Account for this hardware by introducing a set of new z_soc_irq_* functions that can override the default behaviour. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2023-01-03 17:56:18 +01:00
config RISCV_SOC_HAS_CUSTOM_IRQ_LOCK_OPS
bool
help
Hidden option to allow SoC to overwrite arch_irq_lock(),
arch_irq_unlock() and arch_irq_unlocked() functions with
platform-specific versions named z_soc_irq_lock(), z_soc_irq_unlock()
and z_soc_irq_unlocked().
Enable this hidden option and specialize the z_soc_* functions when
the RISC-V SoC needs to do something different and more than reading and
writing the mstatus register to lock and unlock the IRQs.
soc: riscv: Add ability to use custom sys_io functions Add Kconfig RISCV_SOC_HAS_CUSTOM_SYS_IO symbol so that a riscv SoC can set to specify that it has a custom implementation for sys_io functions. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2023-07-25 17:50:40 +08:00
config RISCV_SOC_HAS_CUSTOM_SYS_IO
bool
help
Hidden option to allow SoC to overwrite sys_read*(), sys_write*() functions with
platform-specific versions named z_soc_sys_read*() and z_soc_sys_write*().
Enable this hidden option and specialize the z_soc_* functions when
the RISC-V SoC needs to do something different and more than reading and
writing the registers.
arch: riscv: introduce `CONFIG_RISCV_GP_PURPOSE` choice Introduce `CONFIG_RISCV_GP_PURPOSE` choice to make sure that only one of `CONFIG_RISCV_GP` or `CONFIG_RISCV_CURRENT_VIA_GP` can be enabled, instead of relying of dependencies. To do that, introduce a new `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING` that can be selected by SoC when it implemented global pointer (GP) initialization for relative addressing in its linker. `CONFIG_RISCV_GP` will be the default choice when `CONFIG_RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING=y` Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-11-25 12:54:01 +08:00
config RISCV_SOC_HAS_GP_RELATIVE_ADDRESSING
bool
help
Selected when SoC has implemented the initialization of global pointer (GP)
at program start, or earlier than any instruction using GP relative addressing.
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
config RISCV_SOC_CONTEXT_SAVE
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "SOC-based context saving in IRQ handlers"
arch: soc: riscv32: Separate soc offsets from soc context save The zero-riscy core on the rv32m1 soc does not implement hardware loop extensions and thus should not enable RISCV_SOC_CONTEXT_SAVE, however it does still need access to the EVENTx_INTPTPENDCLEAR symbol which comes from GEN_SOC_OFFSET_SYMS(). Split out the soc offset symbols into a separate config so we can enable them without enabling soc context saving. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
2018-12-02 18:46:26 -06:00
select RISCV_SOC_OFFSETS
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
help
arch: riscv32: provide a general mechanism for saving SoC context RISC-V permits myriad extensions to the ISA, any of which may imply additional context that must be saved and restored on ISR entry and exit. The current in-tree example is the Pulpino core, which has extra registers used by ISA extensions for running loops that shouldn't get clobbered by an ISR. This is currently supported by including pulpino-specific definitions in the generic architecture code. This works, but it's a bit inelegant and is something of a layering violation. A more generic mechanism is required to support other RISC-V SoCs with similar requirements without cluttering the arch code too much. Provide that by extending the semantics of the existing CONFIG_RISCV_SOC_CONTEXT_SAVE option to allow other SoCs to allocate space for saving and restoring their own state, promoting the currently pulpino-specific __soc_save_context / __soc_restore_context routines to a RISC-V arch API. The cost of making this generic is two more instructions in each ISR to pass the SoC specific context to these routines in a0 rather than just assuming the stack points to the right place. This is minimal, and should have been done anyway to keep with the ABI. As a first (and currently only in-tree) customer, convert the Pulpino SoC code to this new mechanism. Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-11-01 22:25:13 -06:00
Enable low-level SOC-specific context management, for SOCs
with extra state that must be saved when entering an
interrupt/exception, and restored on exit. If unsure, leave
this at the default value.
Enabling this option requires that the SoC provide a
soc_context.h header which defines the following macros:
- SOC_ESF_MEMBERS: structure component declarations to
allocate space for. The last such declaration should not
end in a semicolon, for portability. The generic RISC-V
architecture code will allocate space for these members in
a "struct soc_esf" type (typedefed to soc_esf_t), which will
be available if arch.h is included.
- SOC_ESF_INIT: structure contents initializer for struct soc_esf
state. The last initialized member should not end in a comma.
The generic architecture IRQ wrapper will also call
arch: riscv32: follow-on tweaks A couple of follow-on patches suggested after previous RISCV32 arch changes were merged. Tweak some help in arch/riscv32/kconfig to better work with the RST docs. Take out all the CONFIG_PRINTK ifdeffery in fatal.c. The cause_str() routine should get compiled out if PRINTK=n anyway. Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-12-07 09:29:14 -08:00
\_\_soc_save_context and \_\_soc_restore_context routines at
arch: riscv32: provide a general mechanism for saving SoC context RISC-V permits myriad extensions to the ISA, any of which may imply additional context that must be saved and restored on ISR entry and exit. The current in-tree example is the Pulpino core, which has extra registers used by ISA extensions for running loops that shouldn't get clobbered by an ISR. This is currently supported by including pulpino-specific definitions in the generic architecture code. This works, but it's a bit inelegant and is something of a layering violation. A more generic mechanism is required to support other RISC-V SoCs with similar requirements without cluttering the arch code too much. Provide that by extending the semantics of the existing CONFIG_RISCV_SOC_CONTEXT_SAVE option to allow other SoCs to allocate space for saving and restoring their own state, promoting the currently pulpino-specific __soc_save_context / __soc_restore_context routines to a RISC-V arch API. The cost of making this generic is two more instructions in each ISR to pass the SoC specific context to these routines in a0 rather than just assuming the stack points to the right place. This is minimal, and should have been done anyway to keep with the ABI. As a first (and currently only in-tree) customer, convert the Pulpino SoC code to this new mechanism. Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-11-01 22:25:13 -06:00
ISR entry and exit, respectively. These should typically
be implemented in assembly. If they were C functions, they
would have these signatures:
``void __soc_save_context(soc_esf_t *state);``
``void __soc_restore_context(soc_esf_t *state);``
The calls obey standard calling conventions; i.e., the state
pointer address is in a0, and ra contains the return address.
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: soc: riscv32: Separate soc offsets from soc context save The zero-riscy core on the rv32m1 soc does not implement hardware loop extensions and thus should not enable RISCV_SOC_CONTEXT_SAVE, however it does still need access to the EVENTx_INTPTPENDCLEAR symbol which comes from GEN_SOC_OFFSET_SYMS(). Split out the soc offset symbols into a separate config so we can enable them without enabling soc context saving. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
2018-12-02 18:46:26 -06:00
config RISCV_SOC_OFFSETS
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "SOC-based offsets"
arch: soc: riscv32: Separate soc offsets from soc context save The zero-riscy core on the rv32m1 soc does not implement hardware loop extensions and thus should not enable RISCV_SOC_CONTEXT_SAVE, however it does still need access to the EVENTx_INTPTPENDCLEAR symbol which comes from GEN_SOC_OFFSET_SYMS(). Split out the soc offset symbols into a separate config so we can enable them without enabling soc context saving. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
2018-12-02 18:46:26 -06:00
help
Enabling this option requires that the SoC provide a soc_offsets.h
header which defines the following macros:
- GEN_SOC_OFFSET_SYMS(): a macro which expands to
GEN_OFFSET_SYM(soc_esf_t, soc_specific_member) calls
to ensure offset macros for SOC_ESF_MEMBERS are defined
in offsets.h. The last one should not end in a semicolon.
See gen_offset.h for more details.
arch: riscv: add RISCV_HAS_(C|P)LIC from soc/riscv Because these are general RISC-V options, not soc specific. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-01-16 16:01:41 +01:00
config RISCV_HAS_PLIC
bool
depends on RISCV_PRIVILEGED
help
Does the SOC provide support for a Platform Level Interrupt Controller (PLIC).
config RISCV_HAS_CLIC
bool
depends on RISCV_PRIVILEGED
arch: riscv: handle interrupt level for CLIC CLIC supports mintstatus.MIL (RO) and mcause.MPIL (RW) for the current interrupt level and the previous interrut level before a trap. Each ISR must execute MRET to set mcause.MPIL back to mintstatus.MIL. This commit introduces CONFIG_CLIC_SUPPORT_INTERRUPT_LEVEL to handle mcause.MPIL for interrupt preemption in nested ISR, and uses CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL to ensure ISR always switch out with MRET. e.g. With CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL=n, a context-switch in ISR may skip MRET in this flow: IRQ -> _isr_wrapper -> z_riscv_switch() -> retrun to arch_switch() Signed-off-by: Jimmy Zheng <jimmyzhe@andestech.com>
2024-07-03 17:11:12 +08:00
select RISCV_ALWAYS_SWITCH_THROUGH_ECALL if MULTITHREADING
select CLIC_SUPPORT_INTERRUPT_LEVEL if !NRFX_CLIC
arch: riscv: add RISCV_HAS_(C|P)LIC from soc/riscv Because these are general RISC-V options, not soc specific. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-01-16 16:01:41 +01:00
help
Does the SOC provide support for a Core-Local Interrupt Controller (CLIC).
arch: riscv: handle interrupt level for CLIC CLIC supports mintstatus.MIL (RO) and mcause.MPIL (RW) for the current interrupt level and the previous interrut level before a trap. Each ISR must execute MRET to set mcause.MPIL back to mintstatus.MIL. This commit introduces CONFIG_CLIC_SUPPORT_INTERRUPT_LEVEL to handle mcause.MPIL for interrupt preemption in nested ISR, and uses CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL to ensure ISR always switch out with MRET. e.g. With CONFIG_RISCV_ALWAYS_SWITCH_THROUGH_ECALL=n, a context-switch in ISR may skip MRET in this flow: IRQ -> _isr_wrapper -> z_riscv_switch() -> retrun to arch_switch() Signed-off-by: Jimmy Zheng <jimmyzhe@andestech.com>
2024-07-03 17:11:12 +08:00
config CLIC_SUPPORT_INTERRUPT_LEVEL
bool
depends on RISCV_HAS_CLIC
help
For CLIC implementations with extended interrupt level, where
higher-numbered interrupt levels can preempt lower-numbered interrupt
levels. This option handles interrupt level in ISR to ensure proper
nested ISR exits.
arch: riscv: make __soc_is_irq optional It looks like all SoCs in tree check if an exception comes from an IRQ the same way, so let's provide a common logic by default, still customizable if the SoC selects RISCV_SOC_ISR_CHECK. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-01-16 16:31:26 +01:00
config RISCV_SOC_EXCEPTION_FROM_IRQ
bool
help
Option selected by SoCs that require a custom mechanism to check if
an exception is the result of an interrupt or not. If selected,
__soc_is_irq() needs to be implemented by the SoC.
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
config RISCV_SOC_INTERRUPT_INIT
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "SOC-based interrupt initialization"
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
help
kconfig: fix help syntax and add spaces Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-13 10:08:21 -05:00
Enable SOC-based interrupt initialization
(call soc_interrupt_init, within _IntLibInit when enabled)
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: remove SOC from RISCV_SOC_MCAUSE_EXCEPTION_MASK Just to stay consistent with other RISC-V related settings. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-01-10 15:53:24 +01:00
config RISCV_MCAUSE_EXCEPTION_MASK
riscv: Add an option for configuring mcause exception mask GD32V processor core is used non-standard bitmask for mcause register. Add option to configure the bitmask to support GD32V. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
2020-03-03 21:27:10 +09:00
hex
default 0x7FFFFFFFFFFFFFFF if 64BIT
default 0x7FFFFFFF
help
Specify the bits to use for exception code in mcause register.
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
config RISCV_GENERIC_TOOLCHAIN
bool "Compile using generic riscv32 toolchain"
default y
help
kconfig: fix help syntax and add spaces Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-13 10:08:21 -05:00
Compile using generic riscv32 toolchain.
Allow SOCs that have custom extended riscv ISA to still
compile with generic riscv32 toolchain.
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
riscv32: enable gen_isr_tables mechanism Change-Id: Ia09d9a4d3412424dcbb25db829059a0714d81214 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-02-13 10:11:54 -08:00
config GEN_ISR_TABLES
default y
config GEN_IRQ_VECTOR_TABLE
default n
riscv: Add CONFIG_RISCV_RESERVED_IRQ_ISR_TABLES_OFFSET Some RISCV platforms shipping a CLIC have a peculiar interrupt ID ordering / mapping. According to the "Core-Local Interrupt Controller (CLIC) RISC-V Privileged Architecture Extensions" Version 0.9-draft at paragraph 16.1 one of these ordering recommendations is "CLIC-mode interrupt-map for systems retaining interrupt ID compatible with CLINT mode" that is described how: The CLINT-mode interrupts retain their interrupt ID in CLIC mode. [...] The existing CLINT software interrupt bits are primarily intended for inter-hart interrupt signaling, and so are retained for that purpose. [...] CLIC interrupt inputs are allocated IDs beginning at interrupt ID 17. Any fast local interrupts that would have been connected at interrupt ID 16 and above should now be mapped into corresponding inputs of the CLIC. That is a very convoluted way to say that interrupts 0 to 15 are reserved for internal use and CLIC only controls interrupts reserved for platform use (16 up to n + 16, where n is the maximum number of interrupts supported). Let's now take now into consideration this situation in the DT: clic: interrupt-controller { ... }; device0: some-device { interrupt-parent = <&clic>; interrupts = <0x1>; ... }; and in the driver for device0: IRQ_CONNECT(DT_IRQN(node), ...); From the hardware prospective: (1a) device0 is using the first IRQ line of the CLIC (2a) the interrupt ID / exception code of the `MSTATUS` register associated to this IRQ is 17, because the IDs 0 to 15 are reserved From the software / Zephyr prospective: (1b) Zephyr is installing the IRQ vector into the SW ISR table (and into the IRQ vector table for DIRECT ISRs in case of CLIC vectored mode) at index 0x1. (2b) Zephyr is using the interrupt ID of the `MSTATUS` register to index into the SW ISR table (or IRQ vector table) It's now clear how (2a) and (2b) are in contrast with each other. To fix this problem we have to take into account the offset introduced by the reserved interrupts. To do so we introduce CONFIG_RISCV_RESERVED_IRQ_ISR_TABLES_OFFSET as hidden option for the platforms to set. This Kconfig option is used to shift the interrupt numbers when installing the IRQ vector into the SW ISR table and/or IRQ vector table. So for example in the previous case and using CONFIG_RISCV_RESERVED_IRQ_ISR_TABLES_OFFSET == 16, the IRQ vector associated to the device0 would be correctly installed at index 17 (16 + 1), matching what is reported by the `MSTATUS` register. CONFIG_NUM_IRQS must be increased accordingly. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2023-06-07 16:03:45 +02:00
config RISCV_RESERVED_IRQ_ISR_TABLES_OFFSET
int
default 0
depends on GEN_ISR_TABLES
help
On some RISCV platform the first interrupt vectors are primarly
intended for inter-hart interrupt signaling and so retained for that
purpose and not available. When this option is set, all the IRQ
vectors are shifted by this offset value when installed into the
software ISR table and the IRQ vector table. CONFIG_NUM_IRQS must be
properly sized to take into account this offset. This is a hidden
option which needs to be set per architecture and left alone.
arm/riscv: kconfig: Remove type from NUM_IRQS in defconfig files Add a common definition for NUM_IRQS in arch/arm/core/Kconfig and arch/riscv/Kconfig. That way, the type doesn't have to be given for NUM_IRQS in all the Kconfig.defconfig files. Trying to get rid of unnecessary "full" symbol definitions in Kconfig.defconfig files, to make the organization clearer. It can also help with finding unused symbols. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-10-25 12:01:04 +02:00
config NUM_IRQS
int
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
config RV_BOOT_HART
int "Starting HART ID"
default 0
help
This option sets the starting HART ID for the SMP core.
For RISC-V systems such as MPFS and FU540 this would be set to 1 to
skip the E51 HART 0 as it is not usable in SMP configurations.
arch: riscv: introduce a Kconfig to mask `mhartid` Configure a new Kconfig (`CONFIG_RISCV_HART_MASK`) so that it is possible to mask the `mhartid` of a processor. This is helpful in the cases when the hart id starts from non-zero value. Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-03-08 00:00:36 +08:00
config RISCV_HART_MASK
int
default -1
help
Configures the mask for the HART ID.
For RISC-V systems with HART ID starting from non-zero value,
i.e. 128, 129, ..(0x80, 8x81, ..), this can be configured to 63 (0x7f)
such that we can extract the bits that start from 0.
arch: riscv: optionally stores a pointer to csf in `struct arch_esf` The callee-saved-registers can be helpful to debug the state of a core upon an exception, however, currently there's no way to access that information in user-implemented `k_sys_fatal_error_handler()`, even though the csf is already stored in the stack. This patch conditionally add a `csf` member in the `arch_esf` when `CONFIG_EXTRA_EXCEPTION_INFO=y`*, which the `_isr_wrapper` would update when a fatal error occurs before invoking `z_riscv_fatal_error_csf()`. Functions such as `k_sys_fatal_error_handler()` would then be able to access the callee-saved-registers at the time of exception via `esf->csf`. * For SoCs that select `RISCV_SOC_HAS_ISR_STACKING`, the `SOC_ISR_STACKING_ESF_DECLARE` has to include the `csf` member, otherwise the build would fail. Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-09-06 00:13:01 +08:00
config EXTRA_EXCEPTION_INFO
bool "Collect extra exception info"
depends on EXCEPTION_DEBUG
help
This option enables the collection of extra information, such as
register state, when a fault occurs. This information can be useful
to collect for post-mortem analysis and debug of issues.
riscv: rationalize PMP related Kconfig options ARCH_HAS_USERSPACE and ARCH_HAS_STACK_PROTECTION are direct functions of RISCV_PMP regardless of the SoC. PMP_STACK_GUARD is a function of HW_STACK_PROTECTION (from ARCH_HAS_STACK_PROTECTION) and not the other way around. This allows for tests/kernel/fatal/exception to test protection against various stack overflows based on the PMP stack guard functionality. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-05-13 00:00:19 -04:00
config RISCV_PMP
arch: riscv: add pmp support - Set some helper function to write/clear/print PMP config registers. - Add support for different PMP slot size function to core/board. Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
2020-07-21 15:59:23 +02:00
bool "RISC-V PMP Support"
select THREAD_STACK_INFO
arch: mem protect Kconfig cleanups Adds a new CONFIG_MPU which is set if an MPU is enabled. This is a menuconfig will some MPU-specific options moved under it. MEMORY_PROTECTION and SRAM_REGION_PERMISSIONS have been merged. This configuration depends on an MMU or MPU. The protection test is updated accordingly. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-11-05 14:30:20 -08:00
select CPU_HAS_MPU
riscv: rationalize PMP related Kconfig options ARCH_HAS_USERSPACE and ARCH_HAS_STACK_PROTECTION are direct functions of RISCV_PMP regardless of the SoC. PMP_STACK_GUARD is a function of HW_STACK_PROTECTION (from ARCH_HAS_STACK_PROTECTION) and not the other way around. This allows for tests/kernel/fatal/exception to test protection against various stack overflows based on the PMP stack guard functionality. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-05-13 00:00:19 -04:00
select ARCH_HAS_USERSPACE
Revert "riscv: PMP-based stack guard is incompatible with stack sentinel" This reverts commit a7b5d606c7b94cd0c1d5d4d422369e451519d5fe. The assumption behind that commit was wrong. The software-based stack sentinel writes to the very bottom of the _writable_ stack area i.e. right next to the actual PMP based guard area. So they are compatible. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-10-24 13:32:58 -04:00
select ARCH_HAS_STACK_PROTECTION
arch: mem protect Kconfig cleanups Adds a new CONFIG_MPU which is set if an MPU is enabled. This is a menuconfig will some MPU-specific options moved under it. MEMORY_PROTECTION and SRAM_REGION_PERMISSIONS have been merged. This configuration depends on an MMU or MPU. The protection test is updated accordingly. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-11-05 14:30:20 -08:00
select MPU
select SRAM_REGION_PERMISSIONS
arch: riscv: add pmp support - Set some helper function to write/clear/print PMP config registers. - Add support for different PMP slot size function to core/board. Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
2020-07-21 15:59:23 +02:00
select ARCH_MEM_DOMAIN_SYNCHRONOUS_API if USERSPACE
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
select ARCH_MEM_DOMAIN_DATA if USERSPACE
riscv: new TLS-based arch_is_user_context() implementation This reverts the bulk of commit c8bfc2afda2c ("riscv: make arch_is_user_context() SMP compatible") and replaces it with a flag stored in the thread local storage (TLS) area, therefore making TLS mandatory for userspace support on RISC-V. This has many advantages: - The tp (x4) register is already dedicated by the standard for this purpose, making TLS support almost free. - This is very efficient, requiring only a single instruction to clear and 2 instructions to set. - This makes the SMP case much more efficient. No need for funky exception code any longer. - SMP and non-SMP now use the same implementation making maintenance easier. - The is_user_mode variable no longer requires a dedicated PMP mapping and therefore freeing one PMP slot for other purposes. Signed-off-by: Nicolas Pitre <npitre@baylibre.com> 5f65dbcc9dab3d39473b05397e05.
2022-06-07 09:37:59 -04:00
select THREAD_LOCAL_STORAGE if USERSPACE
riscv: pmp: select CONFIG_MEM_DOMAIN_ISOLATED_STACKS RISC-V PMP implementation supports isolating thread stacks within the same memory domain, and also is the only supported operating mode. So select the corresponding kconfig by default. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-04-25 12:10:03 -07:00
select ARCH_MEM_DOMAIN_SUPPORTS_ISOLATED_STACKS
select MEM_DOMAIN_ISOLATED_STACKS
arch: riscv: add pmp support - Set some helper function to write/clear/print PMP config registers. - Add support for different PMP slot size function to core/board. Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
2020-07-21 15:59:23 +02:00
help
MCU implements Physical Memory Protection.
if RISCV_PMP
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
riscv: pmp: rename CONFIG_PMP_SLOT The plural form is clearer. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-07 15:44:42 -04:00
config PMP_SLOTS
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
int "Number of PMP slots"
default 8
help
This is the number of PMP entries implemented by the hardware.
Typical values are 8 or 16.
riscv: pmp: provision for implementations with partial PMP support Looks like some implementors decided not to implement the full set of PMP range matching modes. Let's rearrange the code so that any of those modes can be disabled. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-02-09 13:15:45 -05:00
config PMP_NO_TOR
bool
help
Set this if TOR (Top Of Range) mode is not supported.
config PMP_NO_NA4
bool
help
Set this if NA4 (Naturally Aligned 4-byte) mode is not supported.
config PMP_NO_NAPOT
bool
help
Set this if NAPOT (Naturally Aligned Power Of Two) is not supported.
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
config PMP_POWER_OF_TWO_ALIGNMENT
riscv: pmp: provision for implementations with partial PMP support Looks like some implementors decided not to implement the full set of PMP range matching modes. Let's rearrange the code so that any of those modes can be disabled. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-02-09 13:15:45 -05:00
bool "Enforce power-of-two alignment on PMP memory areas" if !PMP_NO_TOR
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
default y if TEST_USERSPACE
riscv: pmp: rename CONFIG_PMP_SLOT The plural form is clearer. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-07 15:44:42 -04:00
default y if (PMP_SLOTS = 8)
riscv: pmp: provision for implementations with partial PMP support Looks like some implementors decided not to implement the full set of PMP range matching modes. Let's rearrange the code so that any of those modes can be disabled. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-02-09 13:15:45 -05:00
default y if PMP_NO_TOR
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
select MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT
select GEN_PRIV_STACKS
help
This option reduces the PMP slot usage but increases
riscv: rationalize PMP related Kconfig options ARCH_HAS_USERSPACE and ARCH_HAS_STACK_PROTECTION are direct functions of RISCV_PMP regardless of the SoC. PMP_STACK_GUARD is a function of HW_STACK_PROTECTION (from ARCH_HAS_STACK_PROTECTION) and not the other way around. This allows for tests/kernel/fatal/exception to test protection against various stack overflows based on the PMP stack guard functionality. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-05-13 00:00:19 -04:00
memory consumption. Useful when enabling userspace mode with
many memory domains and/or few PMP slots available.
riscv: pmp: switch over to the new implementation Add the appropriate hooks effectively replacing the old implementation with the new one. Also the stackguard wasn't properly enforced especially with the usermode combination. This is now fixed. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-06 22:03:54 -04:00
riscv: pmp: Add kconfig option for granularity of PMP Add Kconfig option CONIFG_PMP_GRANULARITY to specify the granularity of PMP. Signed-off-by: Rick Tsao <rick592@andestech.com>
2023-03-28 10:46:14 +08:00
config PMP_GRANULARITY
int "The granularity of PMP address matching"
default 8 if (PMP_NO_TOR && PMP_NO_NA4)
default 4
help
The granularity must be a power of 2 greater than or equal to 4
(ie 4, 8, 16, ...), but if neither TOR mode nor NA4 mode is
supported, the minimum granularity is 8.
arch: riscv: add pmp support - Set some helper function to write/clear/print PMP config registers. - Add support for different PMP slot size function to core/board. Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
2020-07-21 15:59:23 +02:00
endif #RISCV_PMP
riscv: rationalize PMP related Kconfig options ARCH_HAS_USERSPACE and ARCH_HAS_STACK_PROTECTION are direct functions of RISCV_PMP regardless of the SoC. PMP_STACK_GUARD is a function of HW_STACK_PROTECTION (from ARCH_HAS_STACK_PROTECTION) and not the other way around. This allows for tests/kernel/fatal/exception to test protection against various stack overflows based on the PMP stack guard functionality. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-05-13 00:00:19 -04:00
config PMP_STACK_GUARD
def_bool y
depends on HW_STACK_PROTECTION
config PMP_STACK_GUARD_MIN_SIZE
int "Stack Guard area size"
depends on PMP_STACK_GUARD
default 1024 if 64BIT
default 512
help
The Hardware Stack Protection implements a guard area at the bottom
of the stack using the PMP to catch stack overflows by marking that
guard area not accessible.
This is the size of the guard area. This should be large enough to
catch any sudden jump in stack pointer decrement, plus some
wiggle room to accommodate the eventual overflow exception
stack usage.
arch/riscv: add support for detecting null pointer exception using PMP This change uses a PMP slot to implement null pointer detection. Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
2023-05-23 11:55:43 +08:00
# Implement the null pointer detection using the Physical Memory Protection
# (PMP) Unit.
config NULL_POINTER_EXCEPTION_DETECTION_PMP
bool "Use PMP for null pointer exception detection"
depends on RISCV_PMP
help
Null pointer dereference detection implemented
using PMP functionality.
if NULL_POINTER_EXCEPTION_DETECTION_PMP
config NULL_POINTER_EXCEPTION_REGION_SIZE
hex "Inaccessible region to implement null pointer detection"
default 0x10
help
Use a PMP slot to make region (starting at address 0x0) inaccessible for
detecting null pointer dereferencing (raising a CPU access fault).
Minimum is 4 bytes.
endif # NULL_POINTER_EXCEPTION_DETECTION_PMP
arch: riscv: add Kconfig option for imprecise FPU state tracking According to the RISC-V Instruction Set Manual: Volume II, Version 20240411 (Section 3.1.6.6), some implementations may choose to track the dirtiness of the floating-point register state imprecisely by reporting the state to be dirty even when it has not been modified. This option reflects that. Also add a filter in `tests/arch/riscv/fpu_sharing/` based on imprecise FPU state tracking Signed-off-by: Jakub Wasilewski <jwasilewski@internships.antmicro.com> Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
2024-07-09 13:25:46 +02:00
config RISCV_IMPRECISE_FPU_STATE_TRACKING
bool "Imprecise implementation of FPU state tracking"
depends on FPU
help
According to the RISC-V Instruction Set Manual: Volume II, Version 20240411
(Section 3.1.6.6), some implementations may choose to track the dirtiness of
the floating-point register state imprecisely by reporting the state to be
dirty even when it has not been modified. This option reflects that.
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
endmenu
arch/riscv: boost default stacks Increased stacks required for RISC-V 64-bit CI to pass. Most of these were catched by the kernel stack sentinel. The CMSIS stacks are for programs in samples/portability. Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
2021-01-07 21:16:10 +01:00
config MAIN_STACK_SIZE
default 4096 if 64BIT
riscv: clarify stack size and alignment parameters The StackGuard area is used to save the esf and run the exception code resulting from a StackGuard trap. Size it appropriately. Remove redundancy, clarify documentation, etc. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-04-30 15:12:31 -04:00
default 2048 if PMP_STACK_GUARD
arch/riscv: boost default stacks Increased stacks required for RISC-V 64-bit CI to pass. Most of these were catched by the kernel stack sentinel. The CMSIS stacks are for programs in samples/portability. Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
2021-01-07 21:16:10 +01:00
kconfig: Rename the TEST_EXTRA stack size option to align with the rest All stack sizes should end with STACK_SIZE. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2022-02-17 17:09:09 +01:00
config TEST_EXTRA_STACK_SIZE
riscv: Increase TEST_EXTRA_STACK_SIZE to 4096 if c++ exceptions Initializing the C++ stack unwinding data structures takes quite a bit of stack space. Increase the TEST_EXTRA_STACK_SIZE when using these. Signed-off-by: Keith Packard <keithp@keithp.com>
2025-05-16 09:16:00 -07:00
default 4096 if CPP_EXCEPTIONS
riscv: stack PMP: fix CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT=y case Let's honor CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT even for kernel stacks. This saves one global PMP slot when creating the guard area for the IRQ stack, and some hw implementations might require that anyway. With this changes, arch_mem_domain_max_partitions_get() becomes much more reliable and tests/kernel/mem_protect is more likely to pass even with the stack guard enabled. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2023-01-31 21:08:13 -05:00
default 1536
arch/riscv: boost default stacks Increased stacks required for RISC-V 64-bit CI to pass. Most of these were catched by the kernel stack sentinel. The CMSIS stacks are for programs in samples/portability. Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
2021-01-07 21:16:10 +01:00
config CMSIS_THREAD_MAX_STACK_SIZE
default 1024 if 64BIT
config CMSIS_V2_THREAD_MAX_STACK_SIZE
default 1024 if 64BIT
riscv: Use IRQ vector table for vectored mode For vectored interrupts use the generated IRQ vector table instead of relying on a custom-generated table. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-06-27 10:51:28 +02:00
config ARCH_IRQ_VECTOR_TABLE_ALIGN
default 256
arch: riscv: Trap handler alignment configuration RISC-V Spec requires minimum alignment of trap handling code to be dependent from MTVEC.BASE field size. Minimum alignment for RISC-V platforms is 4 bytes, but maximum is platform or application-specific. Currently there is no common approach to align the trap handling code for RISC-V and some platforms use custom wrappers to align _isr_wrapper properly. This change introduces a generic solution, CONFIG_RISCV_TRAP_HANDLER_ALIGNMENT configuration option which sets the alignment of a RISC-V trap handling code. The existing custom solutions for some platforms remain operational, since the default alignment is set to minimal possible (4 bytes) and will be overloaded by potentially larger alignment of custom solutions. Signed-off-by: Alexander Razinkov <alexander.razinkov@syntacore.com>
2023-09-01 13:55:07 +03:00
config RISCV_TRAP_HANDLER_ALIGNMENT
int "Alignment of RISC-V trap handler in bytes"
riscv: Align _isr_wrapper to 64 bytes for CLIC The CLIC requires that mtvec.base is aligned to 64 bytes. _isr_wrapper is used as mtvec.base, so align it to 64 bytes. Signed-off-by: Piotr Wojnarowski <pwojnarowski@antmicro.com>
2024-05-22 22:04:55 +02:00
default 64 if RISCV_HAS_CLIC
arch: riscv: Trap handler alignment configuration RISC-V Spec requires minimum alignment of trap handling code to be dependent from MTVEC.BASE field size. Minimum alignment for RISC-V platforms is 4 bytes, but maximum is platform or application-specific. Currently there is no common approach to align the trap handling code for RISC-V and some platforms use custom wrappers to align _isr_wrapper properly. This change introduces a generic solution, CONFIG_RISCV_TRAP_HANDLER_ALIGNMENT configuration option which sets the alignment of a RISC-V trap handling code. The existing custom solutions for some platforms remain operational, since the default alignment is set to minimal possible (4 bytes) and will be overloaded by potentially larger alignment of custom solutions. Signed-off-by: Alexander Razinkov <alexander.razinkov@syntacore.com>
2023-09-01 13:55:07 +03:00
default 4
help
This value configures the alignment of RISC-V trap handling
code. The requirement for a particular alignment arises from
the format of MTVEC register which is RISC-V platform-specific.
The minimum alignment is 4 bytes according to the Spec.
riscv: Use IRQ vector table for vectored mode For vectored interrupts use the generated IRQ vector table instead of relying on a custom-generated table. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-06-27 10:51:28 +02:00
config GEN_IRQ_VECTOR_TABLE
arch: riscv: introduce RISCV_PRIVILEGED Introduce a new arch level Kconfig option to signal the implementation of the RISCV Privileged ISA spec. This replaces SOC_FAMILY_RISCV_PRIVILEGED, because this is not a SoC specific property, nor a SoC family. Note that the SoC family naming scheme will be fixed in upcoming commits. Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
2024-01-03 12:39:36 +01:00
select RISCV_VECTORED_MODE if RISCV_PRIVILEGED
riscv: Use IRQ vector table for vectored mode For vectored interrupts use the generated IRQ vector table instead of relying on a custom-generated table. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-06-27 10:51:28 +02:00
arch: riscv: add ARCH_HAS_SINGLE_THREAD_SUPPORT Enable single-threading support for the riscv architecture. Add z_riscv_switch_to_main_no_multithreading function for supporting single-threading. The single-threading does not work with enabling PMP_STACK_GUARD. It is because single-threading does not use context-switching. But the privileged mode transition that PMP depends on implicitly presupposes using context-switching. It is a contradiction. Thus, disable PMP_STACK_GUARD when MULTITHREADING is not enabled. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
2022-07-30 10:26:45 +09:00
config ARCH_HAS_SINGLE_THREAD_SUPPORT
default y if !SMP
arch: reorg the dependencies around (exception) stack trace This commit introduces a new ARCH_STACKWALK Kconfig which determines if the `arch_stack_walk()` is available should the arch supports it. Starting from RISCV, this will be able to converge the exception stack trace implementation & stack walking features. Existing exception stack trace implementation will be updated later. Eventually we will end up with the following: 1. If an arch implements `arch_stack_walk()` `ARCH_HAS_STACKWALK` should be selected. 2. If the above is enabled, `ARCH_SUPPORTS_STACKWALK` indicates if the dependencies are met for arch to enable stack walking. This Kconfig replaces `<arch>_EXCEPTION_STACK_TRACE` 2. If the above is enabled, then, `ARCH_STACKWALK` determines if `arch_stack_walk()` should be compiled. 3. `EXCEPTION_STACK_TRACE` should build on top of the `ARCH_STACKWALK`, stack traces will be printed when it is enabled. 4. `ARCH_STACKWALK_MAX_FRAMES` will be removed as it is replaced by `ARCH_STACKWALK_MAX_FRAMES` Signed-off-by: Yong Cong Sin <ycsin@meta.com> Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
2024-08-14 16:39:03 +08:00
config ARCH_HAS_STACKWALK
bool
default y
imply THREAD_STACK_INFO
help
Internal config to indicate that the arch_stack_walk() API is implemented
and it can be enabled.
riscv: Rework and cleanup Kconfig This patch is doing several things: - Core ISA and extension Kconfig symbols have now a formalized name (CONFIG_RISCV_ISA_* and CONFIG_RISCV_ISA_EXT_*) - a new Kconfig.isa file was introduced with the full set of extensions currently supported by the v2.2 spec - a new Kconfig.core file was introduced to host all the RISCV cores (currently only E31) - ISA and extensions settings are moved to SoC configuration files Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-05-12 12:03:47 +02:00
rsource "Kconfig.isa"
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
endmenu
Copy permalink