Openchip & Software Technologies and SUSE have signed a memorandum of understanding to adapt Linux, Kubernetes and SUSE’s enterprise tools to the future RISC-V processors and accelerators designed by the Barcelona-based company. The agreement aims to ensure that the hardware reaches the market with an environment capable of running artificial intelligence, supercomputing and cloud workloads without relying entirely on architectures controlled outside Europe.
The collaboration does not yet announce a commercial server or a processor available for purchase. It opens an integration effort covering SUSE Linux Enterprise Server, openSUSE Tumbleweed, SUSE Kubernetes Engine, Rancher Prime and SUSE AI Factory. The goal is for the software to be validated when Openchip’s hardware reaches the market, an essential requirement if RISC-V is to move beyond laboratories and into data centres running critical applications.
Openchip and SUSE: the essentials in 20 seconds
- The companies have signed a memorandum of understanding, not a definitive supply agreement.
- SUSE will adapt its enterprise platform to Openchip’s RISC-V processors and accelerators.
- The work will include SUSE Linux Enterprise Server and openSUSE Tumbleweed.
- RKE2 and Rancher Prime will be expected to manage RISC-V nodes and accelerators in Kubernetes.
- The integration covers the RVA23 profile and RVV vector instructions.
- Virtualisation support for cloud environments will also be explored.
- SUSE AI Factory will be combined with Openchip’s inference software.
- The project targets AI, HPC, telecommunications, public administration and regulated sectors.
- The platform is presented as a European option for workloads requiring greater technological control.
- No launch dates, prices, benchmarks or server configurations have yet been announced.
The choice of SUSE makes sense because of its long-standing presence in enterprise Linux. The company maintains a production-oriented distribution, provides long-term support and develops tools for managing Kubernetes clusters. For Openchip, that layer reduces the risk of presenting an accelerator that is technically capable but difficult to install, update or integrate into the platforms companies already use.
RISC-V provides an open instruction set architecture. Each manufacturer can develop its own cores and accelerators without relying on an x86 or Arm licence to define the basic instruction set. That freedom helps companies design specialised chips, although it does not solve the more difficult problem by itself: building the software needed to use them.
The RISC-V challenge does not end when the chip boots Linux
Getting the Linux kernel to start on a platform is only the first step. An enterprise system needs stable firmware, drivers, compilers, libraries, virtualisation, security updates, container images and diagnostic tools.
It must also run applications created for other architectures. Most data-centre software is distributed today for x86-64 and, to a lesser extent, Arm64. Even when an application is open source, compiling it for RISC-V does not guarantee the same performance or that all of its dependencies will be available.
The agreement between Openchip and SUSE aims to begin that work before the hardware reaches production. Early collaboration makes it possible to test the kernel, compilers and libraries on prototypes, identify extensions that need support and prepare certification processes.
| Technology layer | Work required |
|---|---|
| Firmware and boot | Hardware initialisation, UEFI, error management and updates |
| Linux kernel | CPU, memory, interrupts, power management, PCIe and drivers |
| Compilers | GCC and LLVM optimisation for Openchip cores |
| Libraries | Linear algebra, cryptography, communications and AI runtimes |
| Virtualisation | KVM, isolation, device assignment and workload migration |
| Containers | RISC-V images, runtimes and multi-architecture registries |
| Kubernetes | Accelerator discovery, allocation and monitoring |
| Observability | Usage, temperature, error and performance metrics |
| Security | Verified boot, patches, package signing and supply-chain controls |
| Enterprise support | Maintenance cycles, certification and incident resolution |
SUSE Linux Enterprise Server will provide the foundation for commercially supported deployments. openSUSE Tumbleweed can serve as a faster-moving integration environment because its rolling-release model allows recent kernel versions, compilers and tools to arrive earlier.
Using both distributions is useful. Tumbleweed can receive the improvements required by new hardware sooner, while SLES needs a more controlled pace, regression testing and longer maintenance commitments.
One of the technical areas covered by the agreement is the RVA23 profile. RISC-V allows many extensions to be combined, but that flexibility can fragment the market if each processor implements different capabilities. Profiles define a shared baseline that operating systems and compilers can assume.
RVA23 includes the RVV vector extension as part of that baseline. Vector instructions allow one operation to be applied to several data elements and are useful in scientific simulation, signal processing, cryptography, multimedia and artificial intelligence.
Supporting an instruction does not, however, guarantee strong performance. Speed will depend on the actual width of the vector units, cache, memory, core count and the compiler’s ability to generate suitable code.
Openchip and SUSE will need to validate complete workloads rather than isolated instructions. An accelerator may deliver high theoretical mathematical performance and still be constrained by data movement, memory or communication between nodes.
Kubernetes will need to understand Openchip hardware
Most current AI platforms are managed through Kubernetes. Accelerators are presented to the cluster as specialised resources that must be discovered, reserved and assigned to each container.
Nvidia uses device plugins, operators and libraries so that Kubernetes can recognise its GPUs. AMD follows a similar path with Instinct accelerators. Openchip will need an equivalent layer if its devices are to be used without configuring each node manually.
The agreement includes extensions for SUSE Kubernetes Engine, based on RKE2, and Rancher Prime. In practice, this may involve plugins that tell the cluster how many accelerators are available, what state they are in and what capabilities each device provides.
Tools will also be needed to install drivers, update firmware and collect metrics. In an environment with hundreds of servers, these tasks cannot depend on an administrator connecting to every machine through SSH.
A Kubernetes operator could automate part of the process:
- Detect an accelerator installed in the node.
- Check the firmware and driver version.
- Install compatible components.
- Publish the resource to Kubernetes.
- Assign it to containers that request it.
- Collect usage and error metrics.
- Remove the node from service when maintenance is required.
Managing multi-architecture workloads will be another challenge. Many data centres are likely to combine x86, Arm and RISC-V servers for years. Rancher will need to allow an application to select the appropriate node and registries to store images compatible with each architecture.
Developers will have to publish multi-architecture images or compile specific versions. Some applications written in Java, Go or interpreted languages may move relatively easily. Others depend on native libraries, assembly code or extensions available only for x86.
The value of the agreement will lie in reducing that gap. A company will not choose RISC-V simply because the architecture is open. It will choose it when an application can be deployed using the same automation, observability and support processes already in place.
A sovereign platform, but not one isolated from the world
Openchip and SUSE present the project as sovereign European infrastructure. The term requires more precision than a simple marketing label.
RISC-V is open but international. SUSE has European roots and Openchip designs in Barcelona, although semiconductor manufacturing depends on foundries, tools and suppliers distributed across several continents.
A chip designed in Europe may use US design automation software, be manufactured in Asia, integrate South Korean memory and be assembled in another country. Real sovereignty does not necessarily require every part to be made within the European Union, but it does require visibility into dependencies and the ability to maintain the most sensitive components.
| Area | What greater European control would involve |
|---|---|
| Architecture | Ability to design and modify the processor |
| Intellectual property | Rights over cores, accelerators and interconnects |
| Operating system | Auditable code and support controlled from Europe |
| Firmware | Access to updates and signing processes |
| Orchestration | Cluster management without dependence on an external service |
| Data and models | Choice of location and jurisdiction |
| Supply chain | Knowledge of suppliers and alternatives |
| Operations | Control of identities, keys and administration |
| Maintenance | Ability to fix vulnerabilities over the long term |
The collaboration may provide greater control over architecture, operating system and operations. It does not remove dependence on advanced foundries, HBM memory, high-speed networking or semiconductor manufacturing equipment.
It also does not automatically make the platform compliant with NIS2, DORA or the Cyber Resilience Act. These regulations address risk management, continuity, suppliers, incident notification and secure product maintenance.
Infrastructure with auditable components and European support can make part of that work easier, but each organisation will still need controls, testing and documentation.
Open-source software offers another advantage: if a vendor abandons a product, the customer retains at least the technical possibility of reviewing the code, maintaining a version or hiring another company. That option is not always simple or inexpensive, but it reduces absolute lock-in compared with a fully closed platform.
AI and HPC will test the real performance
Openchip is targeting its future accelerators at artificial intelligence and high-performance computing. These are two markets where processor architecture matters, but software often decides which hardware can actually be used.
Nvidia maintains its position through CUDA, mathematical libraries, compilers and the tools surrounding its GPUs. AMD is trying to close that gap with ROCm. Intel develops its own software layers for CPUs and accelerators.
Openchip will need to provide an environment capable of running models and scientific applications without forcing developers to rewrite large amounts of code. Compatibility with frameworks, inference libraries and model formats will matter as much as any announced teraflop figure.
SUSE AI Factory can provide the layer for deploying and managing models, while Openchip would supply the hardware and execution software for its accelerators. The integration will need to answer practical questions: which frameworks will be supported, what numerical formats the chip can handle, how much memory it will provide and how it will scale across several nodes.
Those answers have not yet been published. The memorandum describes the areas of work but provides no performance, power, latency or cost results.
That distinction matters because the agreement should not be presented as a finished alternative to Nvidia, AMD, Intel or Arm. Openchip and SUSE are preparing the foundations for such an option, but they still need to turn the architecture into manufactured hardware and the software into a certified platform.
The most relevant progress lies in beginning the integration before launch. Europe has funded several processor projects that later struggled to find applications and customers. A chip without well-supported Linux, Kubernetes, tools and an active community risks remaining limited to demonstrations.
SUSE and Openchip are trying to avoid that outcome. The result will be measurable when an administrator can install SLES, add several RISC-V nodes to Rancher, deploy a model and maintain it using the same procedures employed in any other data centre.
Frequently asked questions
What have Openchip and SUSE signed?
A memorandum of understanding to adapt and validate SUSE’s Linux and Kubernetes platform on Openchip’s future RISC-V processors and accelerators.
Will Openchip have its own Linux distribution?
That is not what has been announced. The collaboration is based on SUSE Linux Enterprise Server and openSUSE Tumbleweed, together with Kubernetes and enterprise management tools.
What does RVA23 provide?
It defines a common baseline for 64-bit RISC-V processors and includes vector instructions relevant to AI, HPC and data processing.
Can the platform already replace x86 servers or Nvidia GPUs?
Not yet. No commercial systems, prices or benchmarks have been published. The collaboration is intended to prepare the software required for future testing and deployments.