On Fri, 2020-06-26 at 15:12 -0400, Jonathan Behrens wrote:

On Wed, Jun 24, 2020 at 1:55 PM Atish Patra <Atish.Patra@...>
wrote:

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/

From that link it looks like the OS already has access to the kernel
command line and the EFI system table before it starts looking at the
DT / ACPI tables?

Yes. ACPI is only usable via UEFI boot. Thus, EFI system table is
already available with kernel. Even though kernel looks at DT, before
looking at EFI system table, it removes all the memory mappings from DT
for efi boot and reinitilizes all memory blocks from efi memory
mappings.

In that case, the bootloader has already passed enough relevant
information for the OS to know that it isn't about to dereference a
bad pointer or something when trying to read from the DT.

However, perhaps I've been too pessimistic about the RISC-V ecosystem
all conforming to the Unix-class platform spec. I'm way more familiar
with x86 which didn't really manage to achieve something like this,
but it looks like maybe ARM did?

I guess ARM has to do it because it had to support both DT & ACPI
unlike x86. We may have to follow similar approach for RISC-V as well
in future.

If changes like adding ACPI tables or whatever are all done in a
compatible way (say by having a stub DT) there there is no need for a
magic number. If there are going to be multiple conflicting
standards, then proactively using one out of the 31 registers to tell
the apart might be worthwhile.

I am hoping there will not be any conflicting standards and we add
everything in a compatiable way. For Linux land, we try to keep single
Linux kernel image booting all platforms (supporting S-mode).

Jonathan

PS: I started this thread focusing on a small/not too technical
question partially in the hope of generating more discussion on this
mailing list. Please chime in if you have thoughts!

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