A source library xPack with the µOS++ RISC-V architecture definitions
This project provides the architecture-riscv source library as an xPack dependency and includes architecture definitions for RISC-V embedded projects.
The project is hosted on GitHub as micro-os-plus/architecture-riscv-xpack.
This page is addressed to developers who plan to include this source library into their own projects.
For maintainer info, please see the README-MAINTAINER file.
As a source library xPack, the easiest way to add it to a project is via xpm, but it can also be used as any Git project, for example as a submodule.
For details please follow the instructions in the xPack install page.
This package is available from npmjs.com as
cd my-project xpm init # Unless a package.json is already present xpm install @micro-os-plus/architecture-riscv@latest ls -l xpacks/micro-os-plus-architecture-riscv
If, for any reason, xpm is not available, the next recommended
solution is to link it as a Git submodule below an
cd my-project git init # Unless already a Git project mkdir -p xpacks git submodule add https://github.com/micro-os-plus/architecture-riscv-xpack.git \ xpacks/micro-os-plus-architecture-riscv
Apart from the unused
master branch, there are two active branches:
xpack, with the latest stable version (default)
xpack-develop, with the current development version
All development is done in the
xpack-develop branch, and contributions via
Pull Requests should be directed to this branch.
When new releases are published, the
xpack-develop branch is merged
This source xPack provides general RISC-V definitions and will eventually include the implementation for a hardware abstraction layer, which, for RISC-V is not yet standardized.
The architecture-riscv source library is fully functional, but minimalistic, for running semihosted tests.
From a top down approach, in µOS++, the RISC-V definitions are grouped by several criteria:
- platform (board)
- hart (hardware thread)
The platform level refers to a device and adds platform specific definitions, like what GPIO pins are used for various LEDs, buttons, etc.
The portable way to include platform specific definitions in an application is:
In µOS++, the platform specific definitions are grouped in the
An example of a platform package is sifive/platform-sifive-hifive1 with the SiFive HiFive1 small development board.
The RISC-V documentation introduces the term platform as:
A RISC-V hardware platform can contain one or more RISC-V-compatible processing cores together with other non-RISC-V-compatible cores, fixed-function accelerators, various physical memory structures, I/O devices, and an interconnect structure to allow the components to communicate.
In modern implementations, this is generally either a physical chip or a synthesised one.
In other contexts, platform has a broader meaning and may refer to the environment in which a piece of software is executed; it may be the hardware or the operating system (OS); to avoid confusions, in µOS++ the term device is used to identify the vendor specific RISC-V details (with platform being used for the machine, or the board).
Please note that RISC-V defines some common MMIO registers (like
mtimecmp), but, for more flexibility, leaves the
implementation to define the actual address. Unfortunately this
increases the software complexity, since the device specific headers
must define some fixed symbols and the header files must be included
in a careful order, to avoid circular references.
In µOS++, the device specific definitions are grouped in the
The portable way to include device specific definitions in an application is:
Example of device packages are sifive/devices with the SiFive Freedom E310 and E31/E51 Arty devices.
The RISC-V documentation introduces the term core as:
A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible hardware threads, or harts, through multi-threading.
In µOS++, the core specific definitions are grouped in the
The portable way to include architecture specific definitions in an application is:
Hardware threads are the working horses of the software threads; each hardware thread has its own set of general registers and Control and Status Registers (CSRs); the OS may schedule a maximum number of software threads equal with the number of hardware threads, possibly with some grouping constrains.
In RISC-V, Control and Status Registers (CSRs) are
a special group of registers, available via specific
instructions from a separate addressing space not visible in
the memory space.
hart specific definitions are grouped under the
Interrupts and exceptions are grouped under
Build & integration info
The project is written in C++ and assembly and it is expected to be used in C and C++ projects.
The source code was compiled with riscv-none-elf-gcc 12, and should be warning free.
To ease the integration of this package into user projects, there are already made CMake and meson configuration files (see below).
For other build systems, consider the following details:
The following folders should be passed to the compiler during the build:
The header files to be included in user projects are:
The source files to be added to user projects are:
-std=c++20or higher for C++ sources
-std=c11for C sources
To integrate the architecture-riscv source library into a CMake application, add this folder to the build:
The result is an interface library that can be added as an application dependency with:
target_link_libraries(your-target PRIVATE micro-os-plus::architecture-riscv )
To integrate the architecture-riscv source library into a meson application, add this folder to the build:
The result is a dependency object that can be added to an application with:
exe = executable( your-target, link_with: [ # Nothing, not static. ], dependencies: [ micro_os_plus_architecture_riscv_dependency, ] )
Change log - incompatible changes
According to semver rules:
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
The incompatible changes, in reverse chronological order, are:
- v4.x: move rtos-port outside
- v3.x: move rtos-port to separate folder
- v2.x: rename micro_os_plus