software/src/opensbi.git/firmware/fw_base.S, branch master

firmware: Fix comment after relocation completion

2026-06-28T08:38:14+00:00

After relocation is done, the code is running from the load address, not the link address. Fix the comment to correctly reflect this. Signed-off-by: Zong Li Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260626022121.1885209-1-zong.li@sifive.com Signed-off-by: Anup Patel

lib: sbi: Move Zkr entropy initialization from fw_base.S to init_coldboot

2026-05-09T07:29:43+00:00

Current placement of entropy initialization via Zkr extension requires a trap-based mechanism to handle absent Zkr extension case. In presence of Smrnmi extension no trap-based mechanisms should be used before Smrnmi is detected and enabled otherwise trap will jump to undefined location. Move stack guard initialization into init_coldboot function body after device tree has been parsed so we know if Zkr extension is implemented by the platform which helps to avoid trap-based discovery. init_coldboot() is a safe place to initialize entropy because it doesn't return so no check of __stack_chk_guard against value on entry will be done. Signed-off-by: Evgeny Voevodin Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/acd52b0f3468758bc5f09e6a45662341b31d4d87.1778176768.git.evvoevod@tenstorrent.com Signed-off-by: Anup Patel

firmware: Add RNMI handler infrastructure

2026-05-09T07:29:43+00:00

Implement basic Resumable NMI (RNMI) handler support for the RISC-V Smrnmi extension. The new _trap_rnmi_handler assembly entry point saves context using the Smrnmi MN* CSRs (MNSCRATCH, MNEPC, MNSTATUS, MNCAUSE) and returns via mnret. It dispatches to sbi_trap_rnmi_handler(), which optionally calls a platform-specific ops->rnmi_handler callback for actual NMI processing. If no platform handler is registered or it fails, the event is reported as an unhandled NMI. The RNMI handler reuses the generic trap context structure but stores MN* CSR values (MNEPC, MNSTATUS, MNCAUSE) into the corresponding generic fields (mepc, mstatus, cause) for compatibility with existing trap infrastructure. Signed-off-by: Evgeny Voevodin Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/050ae6d2762ba8d5b9dfb3cc1960a23aa3d6c549.1778176768.git.evvoevod@tenstorrent.com Signed-off-by: Anup Patel

include: sbi_scratch: Add tmp1 scratch space for RNMI context saving

2026-05-09T07:29:43+00:00

RNMI handlers use MNSCRATCH instead of MSCRATCH and need separate scratch space from regular trap handling. Add tmp1 for RNMI context while tmp0 remains for regular traps. Signed-off-by: Evgeny Voevodin Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/0a5d241fa1db03e71a3f56be24708cbbc8037e28.1778176768.git.evvoevod@tenstorrent.com Signed-off-by: Anup Patel

firmware: Initialize stack guard via Zkr

2026-02-20T05:53:13+00:00

Try to initialize stack protection guard via the zkr extension. Signed-off-by: Xiang W Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260104051812.128496-1-wxjstz@126.com Signed-off-by: Anup Patel

lib: atomics: fix AMO test macros

2025-12-28T15:14:03+00:00

The "RISC-V C API" [1] defines architecture extension test macros says naming rule for the test macros is __riscv_, where is all lower-case. Three extensions dealing with atomics implementation are: "zaamo" consists of AMO instructions, "zalrsc" - LR/SC, "a" extension means both "zaamo" and "zalrsc" Built-in test macros are __riscv_a, __riscv_zaamo and __riscv_zalrsc. Alternative to the __riscv_a macro name, __riscv_atomic, is deprecated. Use correct test macro __riscv_zaamo for the AMO variant of atomics. It used to be __riscv_atomic that is both deprecated and incorrect because it tests for the "a" extension; i.e. both "zaamo" and "zalrsc" If ISA enables only zaamo but not zalrsc, code as it was would not compile. Older toolchains may have neither __riscv_zaamo nor __riscv_zalrsc, so query __riscv_atomic - it should be treated as both __riscv_zaamo and __riscv_zalrsc, in all present cases __riscv_zaamo is more favorable so take is as alternative for __riscv_zaamo [1] https://github.com/riscv-non-isa/riscv-c-api-doc Signed-off-by: Vladimir Kondratiev Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251228073321.1533844-1-vladimir.kondratiev@mobileye.com Signed-off-by: Anup Patel

firmware: Replace sole uses of REGBYTES with __SIZEOF_LONG__

2025-07-22T10:24:27+00:00

This code has nothing to do with the ISA's registers, it's about the format of ELF relocations. As such, __SIZEOF_LONG__, being a language / ABI-level property, is a more appropriate constant to use. This also makes it easier to support CHERI, where general-purpose registers are extended to be capabilities, not just integers, and so the register size is not the same as the machine word size. This also happens to make it more correct for RV64ILP32, where the registers are 64-bit integers but the ABI is 32-bit (both for long and for the ELF format), though properly supporting that ABI is not part of the motivation here, just a consequence of improving the code for CHERI. Signed-off-by: Jessica Clarke Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20250709232932.37622-2-jrtc27@jrtc27.com Signed-off-by: Anup Patel

firmware: Rename __rel_dyn_start/end to __rela_dyn_start/end

2025-07-21T11:09:49+00:00

We are using and expecting the RELA format, not the REL format, and this is the conventional linker-generated name for the start/end symbols, so use it rather than confusing things by making it look like we're accessing .rel.dyn, which would be in the REL format with no explicit addend. Signed-off-by: Jessica Clarke Reviewed-by: Samuel Holland Tested-by: Samuel Holland Link: https://lore.kernel.org/r/20250710002937.44307-1-jrtc27@jrtc27.com Signed-off-by: Anup Patel

firmware: Initial compiler built-in stack protector support

2025-07-20T15:24:34+00:00

Add __stack_chk_fail() and __stack_chk_guard variable which are used by compiler built-in stack protector. This patch just try to support stack-protector so the value of the stack guard variable is simply fixed for now. It could be improved by deriving from a random number generator, such as Zkr extension or any platform-specific random number sources. Introduce three configurations for the stack protector: 1. CONFIG_STACK_PROTECTOR to enable the stack protector feature by providing "-fstack-protector" compiler flag 2. CONFIG_STACK_PROTECTOR_STRONG to provide "-fstack-protector-strong" 3. CONFIG_STACK_PROTECTOR_ALL to provide "-fstack-protector-all" Instead of fixing the compiler flag of stack-protector feature as "-fstack-protector", we derive it from the introduced Kconfig configurations. The compiler flag "stack-protector-cflags-y" is defined as Makefile "immediately expanded variables" with ":=". Thus, the stronger configuration of the stack protector can overwrite the preceding one. Signed-off-by: Alvin Chang Reviewed-by: Yu-Chien Peter Lin Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20250703151957.2545958-3-alvinga@andestech.com Signed-off-by: Anup Patel

lib: Emit lr and sc instructions based on -march flags

2025-03-28T13:22:05+00:00

When -march=rv64im_zalrsc_zicsr is used, provide atomic operations and locks using lr and sc instructions only. Signed-off-by: Chao-ying Fu Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20250226014727.19710-1-cfu@mips.com Signed-off-by: Anup Patel