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
|
