- Proposal: Magic number in boot register
Re: Proposal: Magic number in boot register
On Jun 19, 2020, at 1:26 PM, 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.
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.
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
That's how linux kernel currently detects the SBI version dynamically.
Join firstname.lastname@example.org to automatically receive all group messages.