On Tue, 2020-06-23 at 16:37 -0400, Jonathan Behrens wrote:
>
> On Fri, Jun 19, 2020 at 5:42 PM Atish Patra <Atish.Patra@...>
> wrote:
> > > 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.
> >
>
> The register value would also signal the other elements of this
> platform spec are being followed. Notably including that a1 actually
> points to a valid device tree. If we could count on a device tree
> always being present then I agree that going the /chosen route would
> be cleaner, but if a future third party standard decided to go with
> ACPI tables or something instead then they may not be willing to
> require a dummy device tree just to allow software to blindly
> dereference a1.
>

For ACPI tables, a similar property can be added in the ACPI table.
We anyways have to add other run time properties to ACPI table as we do
currently for the device tree.


> Jonathan
> > > 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