On Jun 19, 2020, at 1:26 PM, Jonathan Behrens <behrensj@...> wrote:

Thanks for that clarification! It is good to know that SBI v0.1 implementations are consistent about returning negative values for functions they don't recognize like sbi_get_spec_version. This however doesn't work for environments which cannot or don't want to implement the SBI at all (what value do you return to say there is no SBI?)

Once RISC-V is more widely deployed, it is likely that there will be more platform specs written by other committees, or even groups entirely outside of the RISC-V foundation. They may not want to require ecalls to detect capabilities, or might have other constraints. Yet, developers will likely want to write kernels that can boot across a range of these different environments. This has certainly been the case on x86 where there's lots of different bootloaders that each work with their own conventions.

Yes. That’s a possibility. If I understand you correctly, you want some identifier that let supervisor know that the M-mode 

firmware is an SBI based one.

If that’s the only case, how about a DT property under /chosen node instead of reserving a register for a fixed value.

To give one case where this already seems to be coming up, Linux can run in M-mode instead of S-mode but only if it is configured that way at compile time. If Linux had a better way to know whether there was firmware present, it might be able to use a shared kernel binary for both cases.

Best,

Jonathan

On Wed, Jun 17, 2020 at 2:56 PM Atish Patra <Atish.Patra@...> wrote:

On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens wrote:
> Hi everyone,
>
> To start off discussion about requirements that should go into the
> platform spec, I propose a simple change to current software:
>
> When entering S-mode for the first time, the a2 register should
> contain the value 0x54414c5058494e55 ("UNIXPLAT").
>
> The intention here is that software should be able to look for this
> value and know that it has been booted in a Supervisor Execution
> Environment that is compliant with the Unix-class platform spec. This
> would distinguish both from old implementations that only support SBI
> v0.1, but also possible future execution environments designed by
> other groups.
>

For SBI version, supervisor systems should use "sbi_get_spec_version"
API to identify what is the SBI version of the SBI implementation. For
v0.1, the above call will return a -ve value indicating that this is a
v0.1.

That's how linux kernel currently detects the SBI version dynamically.


> Jonathan
--
Regards,
Atish