The Supervisor Binary Interface(SBI) specification[1] now defines a
base extension that provides extendability to add future extensions
while maintaining backward compatibility with previous versions.
The new version is defined as 0.2 and older version is marked as 0.1.
This series adds support v0.2 and a unified calling convention
implementation between 0.1 and 0.2. It also add other SBI v0.2
functionality defined in [2]. The base support for SBI v0.2 is already
available in OpenSBI v0.5. This series needs additional patches[3] in
OpenSBI.
Tested on both BBL, OpenSBI with/without the above patch series.
[1] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
[2] https://github.com/riscv/riscv-sbi-doc/pull/27
[3] http://lists.infradead.org/pipermail/opensbi/2019-November/000738.html
Changes from v4->v5
1. Fixed few minor comments related to static & inline.
2. Make sure that every patch is boot tested individually.
Changes from v3->v4.
1. Rebased on top of for-next.
2. Fixed issuses with checkpatch --strict.
3. Unfied all IPI/fence related functions.
4. Added Hfence related SBI calls.
5. Moved to function pointer based boot time switch between v01 and v02 calls.
Changes from v2->v3.
1. Moved v0.1 extensions to a new config.
2. Added support for relacement extensions of v0.1 extensions.
Changes from v1->v2
1. Removed the legacy calling convention.
2. Moved all SBI related calls to sbi.c.
3. Moved all SBI related macros to uapi.
Atish Patra (4):
RISC-V: Mark existing SBI as 0.1 SBI.
RISC-V: Add basic support for SBI v0.2
RISC-V: Introduce a new config for SBI v0.1
RISC-V: Implement new SBI v0.2 extensions
arch/riscv/Kconfig | 6 +
arch/riscv/include/asm/sbi.h | 177 +++++++-----
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/sbi.c | 547 ++++++++++++++++++++++++++++++++++-
arch/riscv/kernel/setup.c | 2 +
5 files changed, 660 insertions(+), 73 deletions(-)
--
2.23.0
On Tue, 26 Nov 2019 11:04:59 PST (-0800), Atish Patra wrote:
> The Supervisor Binary Interface(SBI) specification[1] now defines a
> base extension that provides extendability to add future extensions
> while maintaining backward compatibility with previous versions.
> The new version is defined as 0.2 and older version is marked as 0.1.
>
> This series adds support v0.2 and a unified calling convention
> implementation between 0.1 and 0.2. It also add other SBI v0.2
> functionality defined in [2]. The base support for SBI v0.2 is already
> available in OpenSBI v0.5. This series needs additional patches[3] in
> OpenSBI.
>
> Tested on both BBL, OpenSBI with/without the above patch series.
>
> [1] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> [2] https://github.com/riscv/riscv-sbi-doc/pull/27
> [3] http://lists.infradead.org/pipermail/opensbi/2019-November/000738.html
>
> Changes from v4->v5
> 1. Fixed few minor comments related to static & inline.
> 2. Make sure that every patch is boot tested individually.
>
> Changes from v3->v4.
> 1. Rebased on top of for-next.
> 2. Fixed issuses with checkpatch --strict.
> 3. Unfied all IPI/fence related functions.
> 4. Added Hfence related SBI calls.
> 5. Moved to function pointer based boot time switch between v01 and v02 calls.
> Changes from v2->v3.
> 1. Moved v0.1 extensions to a new config.
> 2. Added support for relacement extensions of v0.1 extensions.
>
> Changes from v1->v2
> 1. Removed the legacy calling convention.
> 2. Moved all SBI related calls to sbi.c.
> 3. Moved all SBI related macros to uapi.
>
> Atish Patra (4):
> RISC-V: Mark existing SBI as 0.1 SBI.
> RISC-V: Add basic support for SBI v0.2
> RISC-V: Introduce a new config for SBI v0.1
> RISC-V: Implement new SBI v0.2 extensions
>
> arch/riscv/Kconfig | 6 +
> arch/riscv/include/asm/sbi.h | 177 +++++++-----
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/sbi.c | 547 ++++++++++++++++++++++++++++++++++-
> arch/riscv/kernel/setup.c | 2 +
> 5 files changed, 660 insertions(+), 73 deletions(-)
There's a few issues with the implementation, but I think the bigger question
is what do to with the spec. The SBI stuff sort of snuck in to Linux without
actually having a proper spec written down, so I'm happy to just say "let's
take the 0.2 stuff as soon as it's frozen" as we're at least in a better spot
than with the legacy stuff. Nominally we'd need to wait for a ratified
specification here, which probably means a 1.0 specification, but that's a way
off and I don't want to just sit around on the legacy stuff.