software/src/opensbi.git, branch release-1.8.x

lib: sbi: Fix behavior on platform without HART protection

2026-01-08T08:48:14+00:00

The commit 42139bb9b7dc ("lib: sbi: Replace sbi_hart_pmp_xyz() and sbi_hart_map/unmap_addr()") changed logic by calling sbi_hart_protection_configure(). But when protection doesn't exist the function is returning SBI_EINVAL. But on systems without protection this is correct configuration that's why do not hang when system don't have any HART protection. Fixes: 42139bb9b7dc ("lib: sbi: Replace sbi_hart_pmp_xyz() and sbi_hart_map/unmap_addr()") Signed-off-by: Michal Simek Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/bb8641e5f82654e3989537cea85f165f67a7044e.1767801896.git.michal.simek@amd.com Signed-off-by: Anup Patel

include: sbi_scratch: fix typo sbi_scratch -> HART id

2026-01-08T07:10:32+00:00

Fix "sbi_scratch" to "HART id" to better reflect its purpose. Signed-off-by: Leo Yu-Chi Liang Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260107032602.1143819-1-ycliang@andestech.com Signed-off-by: Anup Patel

include: Bump-up version to 1.8

2025-12-29T06:54:16+00:00

Update the OpenSBI version to 1.8 as part of release preparation. Signed-off-by: Anup Patel

include: Fix LLVM compile error in sbi_utils/hsm/fdt_hsm_sifive_inst.h

2025-12-28T15:17:12+00:00

Currently, OpenSBI fails to compile for LLVM=1 using 2025.11.27 riscv-gnu-toolchain with the following error: In file included from opensbi/lib/utils/suspend/fdt_suspend_sifive_smc0.c:20: opensbi/include/sbi_utils/hsm/fdt_hsm_sifive_inst.h:17:23: error: expected instruction format 17 | __asm__ __volatile__(".insn 0xfc000073" ::: "memory"); | ^ :1:8: note: instantiated into assembly here 1 | .insn 0xfc000073 | ^ In file included from opensbi/lib/utils/suspend/fdt_suspend_sifive_smc0.c:20: opensbi/include/sbi_utils/hsm/fdt_hsm_sifive_inst.h:12:23: error: expected instruction format 12 | __asm__ __volatile__(".insn 0x30500073" ::: "memory"); | ^ :1:8: note: instantiated into assembly here 1 | .insn 0x30500073 | ^ 2 errors generated. To fix this compile error, use ".word" in-place ".insn". Fixes: 1514a327306b ("lib: utils/hsm: Add SiFive TMC0 driver") Signed-off-by: Anup Patel Link: https://lore.kernel.org/r/20251227100916.327524-1-anup.patel@oss.qualcomm.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

include: riscv_asm: Optimize csr_xyz() macros to reduce stack usage

2025-12-27T05:51:27+00:00

When using debug builds, aka., DEBUG=1, csr_write_num() function can trigger stack overflow. This is caused by the large amount of macro expansion of csr_write(...), which, under debug builds, will generate massive amount of stack variables (tested with GCC 13.2.0). The issue is masked previously as we didn't have too many csr_write()'s before commit 55296fd27c0c, but now, it does overflow the default 4KB stack. The csr_read(relaxed) macros already use the "register" modifier to optimize stack usage (perhaps unknowingly?), so this patch just follows suit. Fixes: 55296fd27c0c ("lib: Allow custom CSRs in csr_read_num() and csr_write_num()") Signed-off-by: Bo Gan Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251216052528.18896-1-ganboing@gmail.com Signed-off-by: Anup Patel

lib: sbi_pmu: Fix multiple start and stop operations of FW counters

2025-12-27T05:34:43+00:00

Currently, OpenSBI returns SBI_ERR_ALREADY_STARTED when attempting to start a HW counter that is already started and SBI_ERR_ALREADY_STOPPED when attempting to stop a HW counter that is already stopped. However, this is not yet implemented for FW counters. Add the necessary checks to return the same error codes when attempting the same actions on FW counters. Signed-off-by: James Raphael Tiovalen Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251213104146.422972-1-jamestiotio@gmail.com Signed-off-by: Anup Patel

lib/sbi: optimize domain memory regions copying

2025-12-27T05:12:44+00:00

There are 2 locations where memory regions moved in a bulk, but this implemented in a region-by region move or even swap. Use more effective way. Note, last entry, dom->regions[count], always exists and is empty, copying it replaces clear_region() Signed-off-by: Vladimir Kondratiev Reviewed-by: Samuel Holland Link: https://lore.kernel.org/r/20251208125617.2557594-1-vladimir.kondratiev@mobileye.com Signed-off-by: Anup Patel

lib: sbi: expected trap must always clear MPRV

2025-12-26T10:52:09+00:00

Expected trap must always clear MPRV. Currently it doesn't. There is a security issue here where if firmware was doing ld/st with MPRV=1 and since there would be a expected trap, opensbi will continue to run as MPRV=1. Security impact is DoS where opensbi will just keep trapping. Signed-off-by: Deepak Gupta Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251124220339.3695940-1-debug@rivosinc.com Signed-off-by: Anup Patel

platform: generic: eswin: Add shutdown/reboot support for Hifive Premier P550

2025-12-21T15:32:46+00:00

Hifive Premier P550[1] is a Mini-DTX form factor board with EIC7700X. It has a STM32F407VET6 onboard MCU acting as the BMC, controlling ATX power on/off while providing remote management features. The EIC7700X SoC/SoM communicates with the BMC via UART2, using ESWIN's protocol. The messages transmitted are fixed sizes (267 bytes), and depending on the type, can be directional or bi-directional. The shutdown and cold reboot requests are directional messages from SoC to BMC (NOTIFY type) with CMD_POWER_OFF or CMD_RESTART. The payload of shutdown/cold reboot requests should be empty and are ignored by the BMC at the moment. A HFP (Hifive Premier) specific reset device is registered in addition to the SoC reset device. For shutdown and cold reboot, the board-level reset takes precedence. The definitions of the SoC <-> BMC message protocol is taken from ESWIN's repo [2]. The only file used from that repo is `hf_common.h` It's disjunctively dual licensed as (GPL-2.0-only OR BSD-2-Clause), hence, compatible with the license of OpenSBI. It's heavily modified and renamed as platform/generic/include/eswin/hfp.h. The author and copyright in the original file are retained. Validated shutdown/cold reboot working on Hifive Premier P550. [1] https://www.sifive.com/boards/hifive-premier-p550#documentation [2] https://github.com/eswincomputing/hifive-premier-p550-mcu-patches.git Signed-off-by: Bo Gan Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251218104243.562667-8-ganboing@gmail.com Signed-off-by: Anup Patel