RISC-V: Print SBI info at startup

[mhorne]

Summary

SBI version 0.2 introduces functions for obtaining the details of the
SBI implementation, such as version and implemntation ID. Print this
info at startup when it is available.

Test Plan

Snippet when booting with OpenSBI (which supports v0.2):

WARNING: WITNESS option enabled, expect reduced performance.
Preloaded elf64 kernel "kernel" at 0xffffffc0007cfb20.
SBI: OpenSBI v0.5
SBI Specification Version: 0.2
CPU(0): Unknown Implementer Unknown Processor

Booting with bbl:

WARNING: WITNESS option enabled, expect reduced performance.
Preloaded elf64 kernel "kernel" at 0xffffffc0007cfb20.
SBI: Unknown (Legacy) Implementation
SBI Specification Version: 0.1
CPU(0): Unknown Implementer Unknown Processor

[kp]

sys/riscv/riscv/sbi.c

36 ↗

(On Diff #64223)

Why have OPENSBI_VERSION_MINOR_MASK here and SBI_SPEC_VERS_MINOR_MASK in sbi.h?

106 ↗

(On Diff #64223)

Maybe #define SBI_SPEC_VERS_MAJOR(x) ((x) SBI_SPEC_VERS_MAJOR_MASK) >> SBI_SPEC_VERS_MAJOR_OFFSET)

That'd let you spell this as major = SBI_SPEC_VERS_MAJOR(sbi_spec_version);

[jhb]

sys/riscv/include/sbi.h

44 ↗

(On Diff #64223)

It doesn't hurt to leave this even if it's unused.

sys/riscv/riscv/sbi.c

36 ↗

(On Diff #64223)

This looks to be OpenSBI specific as OpenSBI has its own version separate from the versions of the SBI spec it implements? Perhaps these constants should be in sbi.h if we think they will be used anywhere else, but they are fine to be here for now.

106 ↗

(On Diff #64223)

We mostly open-code these sorts of things in the tree. The Chelsio driver does go full-bore with 4 sets of macros for each field in a register (S_* is the shift count (like _OFFSET), M_* is the mask, G_* does the shift and and and to extract the value, V_* does the shift so you can or them together to build a register value, and F_ is V_*(1) for single-bit fields), but we haven't really adopted anything like that in other parts of the tree.

[mhorne]

Address comments.

[mhorne]

sys/riscv/riscv/sbi.c

36 ↗

(On Diff #64223)

Exactly this. They are implementation specific and seem unlikely to be used elsewhere.

106 ↗

(On Diff #64223)

I think what you suggested is cleaner kp, but if it's not what is widely used I'll keep these as they are.