GitHub-Mirror/opensbi
2
0
Fork 0
mirror of https://github.com/Fishwaldo/opensbi.git synced 2025-03-16 03:41:24 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
RISC-V Open Source Supervisor Binary Interface
24 commits 1 branch 0 tags 2.9 MiB
C 68.3%
Python 25.6%
Makefile 3.3%
Assembly 2.3%
Shell 0.5%
Find a file
Anup Patel 6f02b6938f lib: Introduce bitmap to track HARTs waiting for coldboot 
On QEMU Virt, max supported HARTs are 8 but number of HARTs
actually depend on "-smp" command-line parameter passed to
QEMU. This creates problems in sbi_hart_wake_coldboot_harts()
because when number of HARTs are less than 8.

To tackle this, we introduce a bitmap to track HARTs waiting
for coldboot to finish. We wake only those HARTs who have
set their bit in coldboot bitmap.

Signed-off-by: Anup Patel <anup.patel@wdc.com>
2018-12-21 10:09:33 +05:30
docs/firmware top: Rename "blob" to "firmware" everywhere 2018-12-21 09:52:27 +05:30
firmware top: Rename "blob" to "firmware" everywhere 2018-12-21 09:52:27 +05:30
include/sbi Use wfi for coldboot finish call. 2018-12-20 15:55:27 -08:00
lib lib: Introduce bitmap to track HARTs waiting for coldboot 2018-12-21 10:09:33 +05:30
plat Fix baud rate divisor computation for U540. 2018-12-20 15:38:43 -08:00
.gitignore Added .gitignore 2018-12-20 14:41:36 +09:00
LICENSE Initial commit. 2018-12-11 19:24:06 +05:30
Makefile top: Rename "blob" to "firmware" everywhere 2018-12-21 09:52:27 +05:30
README.md top: Rename "blob" to "firmware" everywhere 2018-12-21 09:52:27 +05:30

README.md

RISC-V Open Source Supervisor Binary Interface (OpenSBI)

The RISC-V Supervisor Binary Interface (SBI) is a recommended interface between:

  1. Platform specific firmware running in M-mode and general-purpose-os/hypervisor/bootloader running in S-mode/HS-mode
  2. Hypervisor runnng in HS-mode and general-purpose-os/bootloader running in VS-mode

The RISC-V SBI specification is maintained as independent project by RISC-V Foundation on Github

The RISC-V OpenSBI project aims to provides an open-source and extensible implementation of the RISC-V SBI specification for point 1) mentioned above. It can be easily extended by RISC-V platform or RISC-V System-on-Chip vendors.

We can create three things using the RISC-V OpenSBI project:

  1. libsbi.a - Generic OpenSBI static library
  2. libplatsbi.a - Platform specific OpenSBI static library (It is libsbi.a plus platform specific hooks represented by "platform" symbol)
  3. firmwares - Platform specific firmware binaries

How to Build?

For cross-compiling, please ensure that CROSS_COMPILE environment variable is set before starting build system.

The libplatsbi.a and firmwares are optional and only built when PLAT=<platform_subdir> parameter is specified to top-level make. (NOTE: <platform_subdir> is sub-directory under plat/ directory)

To build and install Generic OpenSBI library do the following:

  1. Build libsbi.a: make OR make O=<build_directory>
  2. Install libsbi.a and headers: make install OR make I=<install_directory> install

To build and install platform specific OpenSBI library and firmwares do the following:

  1. Build libsbi, libplatsbi, and firmwares: make PLAT=<platform_subdir> OR make PLAT=<platform_subdir> O=<build_directory>
  2. Install libsbi, headers, libplatsbi, and firmwares: make PLAT=<platform_subdir> install OR make PLAT=<platform_subdir> I=<install_directory> install

In addition, we can also specify platform specific command-line options to top-level make (such as PLAT_<xyz> or FW_<abc>) which are described under docs/plat/<platform_name>.md OR docs/firmware/<firmware_name>.md.

Documentation

All our documenation is under docs directory organized in following manner:

  • docs/platform_guide.md - Guidelines for adding new platform support
  • docs/library_usage.md - Guidelines for using static library
  • docs/plat/<platform_name>.md - Documentation for <platform_name> platform
  • docs/firmware/<firmware_name>.md - Documentation for firmware <firmware_name>

We also prefer source level documentation, so wherever possible we describe stuff directly in the source code. This helps us maintain source and its documentation at the same place. For source level documentation we strictly follow Doxygen style. Please refer [Doxygen manual] (http://www.stack.nl/~dimitri/doxygen/manual.html) for details.