1. Messages
  2. Proposal: Magic number in boot register

Re: Proposal: Magic number in boot register

Jonathan Behrens <behrensj@...>
 

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.

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
Join {tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.