Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for running under OpenSBI #87

Open
wants to merge 5 commits into
base: riscv
Choose a base branch
from

Conversation

knightsc
Copy link

OpenSBI is the default bios used for RISC-V running under qemu. This change adds support for enabling the default bios and modifying the start up code of xv6 to support it. I created this change as a way to test out the functionality of OpenSBI but I think it might be a worthwhile change for others as well. OpenSBI is quickly becoming the default on real RISC-V hardware. Having support here opens the possibility of running xv6 on low cost RISC-V hardware in the future.

One note, there are currently four usertests that seem to hang the system

  • forkforkfork
  • openiput
  • killstatus
  • preempt

I believe that all of these are actually broken in the main branch as well and show up in this change due to the change in the timer code. If I tweak the timer in the main branch from 1/10 of a second to something else I can get these same tests to hang. Before I spend time digging into the root issue with these tests though I wanted to submit this pull request and see if there was sufficient interest in having these OpenSBI changes merged into the original project.

The default bios for the virt platform is OpenSBI. A copy of OpenSBI
is included in the QEMU distribution or the latest version can be built
from source here: https://github.com/riscv-software-src/opensbi
When the default bios is used it is loaded at 0x80000000.
Currently OpenSBI is the default bios and reserves a couple
hundred kilobytes for itself. A 2MiB alignment is used for
the new kernel load address simply because it's common in
the Linux world for RISC-V. In reality the kernel load address
could be immediately after OpenSBI. Since the size of OpenSBI
changes using 2MiB should give us plenty of room.
With OpenSBI as the default bios it runs in machine mode.
It takes care of forwarding exceptions and interrupts to
supervisor mode. When a given hart is started at _entry
it is already running in supervisor mode. timervec can be
completely removed since OpenSBI takes care of this.
Copy link

@echtwerner echtwerner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

close PR please. Although the idea to support OpenSBI is great.
Xv6-RISCV doesn’t support OpenSBI by default because it is designed as a minimalist, educational operating system that emphasizes simplicity and clarity over supporting all the features of modern RISC-V environments like OpenSBI.

Here are some reasons why xv6-RISCV doesn’t natively use OpenSBI:

1.	Simplicity: Xv6-RISCV follows the principle of simplicity to make it easier for students to understand. It focuses on teaching the core concepts of an operating system without relying on modern firmware components like OpenSBI.
2.	QEMU Environment: Xv6-RISCV is often run in QEMU, which provides an environment with the basic features of a BIOS, making a more complex firmware like OpenSBI unnecessary. In this context, no additional supervisor firmware is required.
3.	Minimal Hardware Interface: Xv6-RISCV interacts directly with hardware through minimal abstraction layers. The additional complexity introduced by OpenSBI (such as supervisor mode handling) doesn’t align with the operating system’s goal of demonstrating the core concepts of a Unix-like system.

This doesn’t mean xv6-RISCV can’t run with OpenSBI, but it typically requires adjustments to utilize OpenSBI services, especially for hardware initialization and privilege level management. However, the original design is intended to run in a minimal environment to teach essential operating system concepts without depending on complex hardware or firmware interfaces.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants