Oreboot VisionFive 2 support effort

Noticed this on my youtube feeds:

Apparently somebody’s working on porting oreboot to VisionFive 2.

AIUI oreboot (coreboot minus C) is a SPL-like piece of software written in Rust, and they already support the first VisionFive board.


The somebody is the famous (to me at least) Daniel Maslowski. :star_struck:


Uboot is the standard for basically all SBCs, why people want random poop form the PC world to run on SBCs?

CoreBoot which is a PC BIOS replacement, (U)EFI and many others, they are all not meant for anything else than the Intel World and provide nothing better than uboot can already provide (and it provide much more actually)
I have no will to live in a world where risc-v and other embedded CPU need to use ACPI tables. This is a big no.


Oreboot isn’t coreboot, and neither of them are PC specific nor implement a PC BIOS or UEFI replacement; those would optionally run AFTER coreboot/oreboot is done with its job.


Coreboot is not a BIOS or UEFI replacement, it is the bare minimum software needed to initialize the hardware, similar to u-boot SPL.
The difference is that the SPL is designed to run u-boot whereas coreboot can run a BIOS/UEFI implementation, a linux/kexec based bootloader environment,GRUB and even u-boot.


Yes, Coreboot is no longer a replacement for BIOS or UEFI, but that was the intention of the project that was started in 1999 as LinuxBIOS. That’s how I still had it in my head. In the meantime, however, Coreboot supports various other projects as payload, for example both a BIOS API and various BIOS replacements, or even a UEFI replacement.

You must have made a typo, on GitHub and Twitter he calls himself Daniel Maslowski.

1 Like

Let me correct that.
Thanks for pointing that out.

1 Like

Hi, yea that’s me.

We recently merged the initial code, which does the entire DRAM init, so you can now run M-mode payloads already.
I am currently factoring out the SBI implementation that we had for the Allwinner D1 thus far. It will take a while.

Eventually, flashing requires some nice tooling. I would be happy to have someone support the effort. :slight_smile:

Thanks to y’all for chiming in regarding rumors around the oreboot project’s goals/status and the one we forked from, coreboot. To be clear: RISC-V has a group named PRS TG, the Platform Runtime Services Task Group. This group seeks to define, develop and steer UEFI, ACPI and SBI for RISC-V. SBI had been a thing for many years already, which is essentially like a BIOS. We had no desire to implement such a thing in oreboot. However, the way e.g. Linux is implemented requires a drop to S-mode and a Supervisor Binary Interface (SBI) to be present. That originates from the platform architecture and engineering work.

Anyway, TL;DR: You can use oreboot for your personal raw M-mode payload. Enjoy! :partying_face:


Because U-Boot experience is terrible. It usually do not boot out of the box anything except recommended OS installed on recommended media. Want to boot FreeBSD, Haiku, your hobby OS? Or maybe want to boot from USB or SATA? Now you will have to experience the world of pain with cryptic half-documented boot scripts and U-Boot build configurations.

UEFI EDK2 just works, no stupid boot scripts. You just plug any boot media and it will boot fine. You can adjust boot order in nice user-friendly boot menu.

UEFI properly decouple boot loader and OS, it do not use per-OS hacks like extlinux.

1 Like

Hi @CyReVolt, thank you for your work on oreboot.
I have been following your youtube channel, Daniel aka CyReVolt 🐢 - YouTube, on VisionFive2.

Specifically, in “oreboot on VisionFive 2 006: DRAM init done”, at timestamp 57:55/1:03:39, I noticed you made an error in editing live which, I think, you only partially corrected later.
Should it not be:

diff --git a/src/mainboard/starfive/visionfive2/bt0/src/ddrcsr.rs b/src/mainboard/starfive/visionfive2/bt0/src/ddrcsr.rs
index fdae4f0521..cbf5e20dfd 100644
--- a/src/mainboard/starfive/visionfive2/bt0/src/ddrcsr.rs
+++ b/src/mainboard/starfive/visionfive2/bt0/src/ddrcsr.rs
@@ -400,9 +400,9 @@ pub unsafe fn omc_init(
     println!("[DRAM] OMC init PHY");
     // NOTE: This here even worked when I was accidentally off to 0x150 / 0x154.
-    read32(phy_ctrl_base + 0x14c); // 83 << 2
-    let val = read32(phy_ctrl_base + 0x154); // 84 << 2
-    write32(phy_ctrl_base + 0x150, val & 0xF8000000);
+    read32(phy_ctrl_base + 0x014c); // 83 << 2
+    let val = read32(phy_ctrl_base + 0x0150); // 84 << 2
+    write32(phy_ctrl_base + 0x0150, val & 0xF8000000);
     DDR_CSR_CFG3.iter().for_each(|cfg| {
         let addr = (phy_ctrl_base + cfg.reg_nr as usize);

I do not have a github account or a youtube account and did not know how to contact you at the time.

On another topic: (I do not fully understand this) does/will/should oreboot enable the cache ways as described in Section 14.2.1 of SiFive U74-MC Core Complex Manual 21G3.02.00?

If you mean a better way to write the qspi flash/emmc, starfive folks are working on a usb download tool using typec port on this board.

Yea, that was an erratum. It happens every now and then in live streams, I also sometimes say things that are not fully accurate or I misread etc… If something is really off, I usually put a note in the description. So yea, I noticed the mistake, but as the comment says, it worked either way, and I have no idea what it’s even about since there is no documentation available. I asked for it once, and I got offered an NDA, which I cannot sign because I would need to be able to publish the docs. It’s weird with hardware vendors. :grimacing:

Regarding the cache: I’m not sure if that is something the OS kernel could just do. If not, we may need to do it in oreboot. That would be a rather mid-term concern. If you are familiar with it, feel free to let me know here. :slight_smile:


NDA stuff often due to some IP core vendors. They won’t let chip vendors open detailed information to public.

I don’t care. It’s a quality issue on their side if they don’t document things, whatever they decided/bought/etc… It’s up to them to figure it out. It must not be a problem to the end consumer/customer.

We have made a lot of progress in oreboot recently. I had Linux running a bit already, and also lk. Plus someone is working on Zephyr support. Let me know if anyone is intered.

See also: Bootloader recovery tool