EESSI — the European Environment for Scientific Software Installations — is a shared stack of scientific software (compilers, MPI, BLAS, apps) delivered the same way on laptops, clusters, and clouds. OpenSolvers uses it as the baseline for every board A/B we publish.

Official docs: eessi.io/docs · RISC-V repo: dev.eessi.io/riscv.

What it is

EESSI packages a compatibility layer (a portable userland so binaries work across host distros) and a software layer (EasyBuild-built modules: GCC, OpenMPI, FlexiBLAS/OpenBLAS, FFTW, HPL, Quantum ESPRESSO, …). You mount the stack over CernVM-FS (CVMFS) — a read-only, content-addressed filesystem — then module load what you need. Same modules on a desk SBC and on a cluster node.

Why that matters for RISC-V work:

How it works on RISC-V

RISC-V support is still a development stack. Two CVMFS repos cooperate:

Repo Role on RISC-V
/cvmfs/software.eessi.io Production: compat layer + init / Lmod. Not the app binaries.
/cvmfs/dev.eessi.io/riscv Dev software layer: GCC, EasyBuild, foss, OpenBLAS, HPL, … under …/linux/riscv64/generic/

You always init from production; it hands software off to the RISC-V dev repo. Seeing “this production version only provides a RISC-V compatibility layer…” is expected, not a misconfiguration.

export EESSI_VERSION_OVERRIDE=2025.06-001
source /cvmfs/software.eessi.io/versions/2025.06/init/lmod/bash
# → Module for EESSI/2025.06 loaded
# → selected CPU target: riscv64/generic

Proof the tools come from the RISC-V repo:

command -v eb
# …/dev.eessi.io/riscv/versions/2025.06-001/software/linux/riscv64/generic/software/EasyBuild/…/eb

Today every RISC-V host lands on riscv64/generic — one portable build for all cores (U74, X60, X100). CPU-optimised trees (spacemit/x60, profile paths like rva23u64, …) are still in progress upstream; until then we force OpenBLAS TARGET= / local -march when measuring core-specific kernels.

CVMFS on RISC-V: there is often no distro package — build the client from source (or use a known-good .deb for your glibc/libfuse), install cvmfs-config-eessi, and set CVMFS_HTTP_PROXY=DIRECT (or a local Squid) in /etc/cvmfs/default.local. Status: status.eessi.io.

Extending the stack

EESSI-extend layers a writable install tree on top of CVMFS. That is how we ship patched OpenBLAS, U74-tuned kernels, and experiment modules without touching the read-only mirror:

module load EasyBuild/5.3.0
export EESSI_USER_INSTALL="$HOME/eessi-extend"   # must exist
module load EESSI-extend/2025.06-easybuild
eb --from-pr <num> --robot                 # EasyBuild PR → local module
flexiblas add myblas … && flexiblas default myblas

Same xhpl / pw.x binary; only the BLAS (or FFT) backend changes — the methodology behind HPL, BLAS, and the EESSI X60 blog.

On our boards

Board Cores What EESSI gives us
VisionFive 2 4× U74 Scalar baseline; U74-tuned OpenBLAS → HPL 1.69×
Orange Pi RV2 8× X60 Stock RVV + FlexiBLAS A/B; gemv_n fix; IME via local asm
Banana Pi F3 8× X60 Same K1 stack, tighter RAM
Banana Pi SM10 8× X100 + 8× A100 Same init; archdetect → x100; RVA23 / IME2 work next
BeagleV-Ahead 4× C910 Mounted. Init selects riscv64/generic (RVV 1.0 compat layer). C910 vector code is a local GCC 14 xtheadvector OpenBLAS, not this tree

Highlights that started as “stock EESSI vs fixed module”:

Further reading