On Wed, 2020-06-24 at 13:04 -0400, Jonathan Behrens wrote:

But how will the booting OS know whether to look at ACPI tables or
the device tree? Wouldn't you need some register to indicate which
one is being used?

I am not sure how it will be implemented in RISC-V when we have ACPI.
However, this is process followed in ARM64[1]

ACPI tables are passed via UEFI system configuration table while DT
address will be passed in x0. Kernel tries to use DT first if ACPI is
not preferred choice from kernel commandline. If it fails to find a DT,
it will try to use ACPI table if exists.


[1] https://lwn.net/Articles/642050/

Jonathan

On Wed, Jun 24, 2020 at 11:18 AM Atish Patra via lists.riscv.org <
atish.patra=wdc.com@...> wrote:

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