SNsnvzz·Sep 11, 2023
The SBI spec[0] is not a long read.
0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases
In RISC-V SBI and the full boot processriscv-non-isa
riscv-sbi-doc
Makefile2020–2023
riscv-non-isa / riscv-sbi-doc
riscv-sbi-doc
Documentation for the RISC-V Supervisor Binary Interface
4Distinct people
8Mentions
0Explicit recommenders
483GitHub stars
What to know before exploring
What it is
Documentation for the RISC-V Supervisor Binary Interface
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- riscvarchive/riscv-platform-specs · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2020-07-30 21:51:06 UTC to 2023-09-11 10:29:41 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 0 | 5 |
What Hacker News says
8 sources>Is there any merit in having UART at different addresses on different machines?
Is there any advantage to encumbering the ISA by having a fixed memory address?
If what you need is a debug console, use SBI Debug Console Extension[0].
Otherwise, get the address from the device tree, or from the pointer you've been passed by the SPL, if you are the SBI or you run without SBI.
Note that, in the first place, you will be accessing the UART registers using a register as base + an offset.
0. https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/s...
In RISC-V SBI and the full boot processThis is why RISC-V put a lot of effort on the boot process, and put it early.
Relevant specifications include but aren't limited to SBI[0], UEFI protocol[1] and the ongoing platform specification[2].
RISC-V is quite ready to take over the datacenter, workstation and laptop markets, while dodging the issues derived from bespoke everything which other architectures challenging x86 suffer from.
0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases
1. https://github.com/riscv-non-isa/riscv-uefi/releases/
2. https://github.com/riscv/riscv-platform-specs
In StarFive VisionFive 2 SBC Now Supports TianoCore EDK II (UEFI)>What does matter is standardization. For example a booting process.
Truth.
This is why RISC-V put a lot of effort on this, and put it early.
Relevant specs include but isn't limited to SBI[0], UEFI protocol[1] and the ongoing platform specification[2].
0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases
1. https://github.com/riscv-non-isa/riscv-uefi/releases/tag/1.0...
2. https://github.com/riscv/riscv-platform-specs
In ARM or x86? ISA Doesn’t Matter (2021)I wouldn't say SBI there belongs with the others.
For starters, it is a fairly simple, open specification of an interface[0], with an open implementation, opensbi, that so far everybody uses.
Furthermore, it is not "hidden" in any way from the OS, which can take over its roles, partially or completely.
0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases
In PC Engines EOLWell that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot).
The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv/riscv-platform-specs https://github.com/riscv-non-isa/riscv-sbi-doc)
In HiFive Unmatched – A RISC-V Linux development platformI hope RISC-V will get booting right.
https://linuxplumbersconf.org/event/4/contributions/381/atta...
https://www.phoronix.com/scan.php?page=news_item&px=UEFI-RIS...
Early discussions (cannot find a trace online, from my mail archives):
From: ron minnich
Subject: Re: [sw-dev] SBI extension proposal v2
Date: Sat, 10 Nov 2018 08:46:07 -0800
At Google and other places, we've been struggling now for years with
overly complex firmware that is implemented incorrectly, enabling
exploits and other bad things. The list of things vendors get wrong in
firmware, both enabling exploits and enabling others to enable
exploits, is long and it continues to this day. There is an
unbelievable amount of money out there all involving firmware
exploits, very little of it involving nice people.
I'm currently working on deleting all use of the x86 version of M
Read the rest
mode, i.e. SMM. There are many proposals out there for deleting SMM
from the architecture. I've also shown at a talk in 2017 how we could
redirect SMM interrupts back into the kernel. We're also removing all
use of callbacks into UEFI on x86. We're almost there.
Which is why I'm a bit unhappy to see this (to me) cancerous growth in
proposals for M- mode code. PPP in firmware? Really? multiple serial
devices? really? We've been here before, in the 1970s, with something
called the BIOS. If you're not familiar with it, go take a look, or
you can take my word for it that these proposals implement that idea.
We spent over 20 years freeing ourselves from it on x86. Why go back
to a 50 year old model on a CPU designed to be in use for 50 years?
My early understanding of M mode was that it was an Alpha PALCode like
thing, enabling access to resources that were behind a privilege wall.
I did not like it that much, but I was OK: it was very limited in
function, and the kernel could replace it, or at least measure it. I
also accept that every cpu vendor uses m mode like things (e.g. ARM
TF) for reasonable purposes and also (let's be honest here) for
dealing with chipset mistakes. But that does not mean you need to
recreate BIOS.
The SBI should be hard to add to, deliberately. It should be used only
when there are no possible alternatives. It needs to be open source
and held in common. It should be possible for a kernel to replace or
at least measure it. And, further, there needs to be some work done on
why you add to it, and why you don't, with bias against adding to it.
This proposal works against those ideals, as it explicitly enables
vendor-specific forks of the SBI. Sure, this can happen, but why make
it so easy?
see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.
Also, I've had discussions with some security folks in our firmware
community about the fact that the PMP can be used in a way that the
kernel can not measure the SBI, since SBI might read-protect itself.
This is a real step backwards, FYI. Not sure if it can be changed at
this point.
ron
p.s. For interleaving debug and console output firmware, use the
oldest trick in the book: ASCII is 7 bits. Since console out is 8
bits, reserve 128 values for console out, and 128 for debug stream,
and if the debug stream needs 8 bit for some words, you know what to
do. It's very easy and doesn't require that we add multiple UART
support to SBI.
yeah, it usually is, that's how those device trees work. it's generally bundled with the "bootloader" (chain loader component of the firmware). you can even bake them into your kernel if you want, i believe.
RISC-V is a processor ISA, not a platform spec. you may be interested in the SBI: https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi...
the details of how all this stuff works at a human-collaboration level has changed a bit since 1993. there's a higher level of collaboration expected. vs intel and ms bossing people around.
edit: you may also be interested in https://doc.coreboot.org/arch/riscv/index.html and https://lkml.org/lkml/2020/2/25/1209 and https://lists.gnu.org/archive/html/grub-devel/2019-02/msg000...
not exactly "desktop" yet, but hopefully you can see how that might look, given the existing linux infrastructur
Read the rest
e :)