My apologies for digging around in old threads ... I've had an interest
in archaeology since I was quite young :) ....
On 26 Jun 2020 19:29, Atish Patra wrote:
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@...>
On Wed, 2020-06-24 at 13:04 -0400, Jonathan Behrens wrote:
But how will the booting OS know whether to look at ACPI tablesor
the device tree? Wouldn't you need some register to indicatewhich
one is being used?I am not sure how it will be implemented in RISC-V when we have
However, this is process followed in ARM64
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
not preferred choice from kernel commandline. If it fails to find a
it will try to use ACPI table if exists.
I'd forgotten I'd written that :). Yeesh. I was going to argue with
the author -- and I should probably update it.
Yes. ACPI is only usable via UEFI boot. Thus, EFI system table is
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?
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
Somewhat simplified. ACPI can be used without UEFI -- that's how I
did the initial port on arm64. It's not typically used, though; it
is the SBSA/SBBR that require UEFI and ACPI on arm64 servers. The
only real connection between the two is that the EFI system table
provides the address to the beginning of the ACPI data structures.
When booting with UEFI, the memory map is provided by UEFI; the only
thing in the DT is a /chosen node with the kernel arguments that
need to be passed in. An initial 1:1 map is setup, then the UEFI
memory map is read and eventually VM is turned on. Once it has,
then ACPI can start enumerating devices.
The kernel checks this initial DT to see if there is more in it than
the /chosen node. If there is, then it assumes DT is where all of
the device enumeration info is.
In that case, the bootloader has already passed enough relevantI guess ARM has to do it because it had to support both DT & ACPI
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?
unlike x86. We may have to follow similar approach for RISC-V as well
If changes like adding ACPI tables or whatever are all done in aI am hoping there will not be any conflicting standards and we add
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.
everything in a compatiable way. For Linux land, we try to keep single
Linux kernel image booting all platforms (supporting S-mode).
I think the platform spec committee all agrees -- conflicting standards
are A Really Bad Idea. And this is *definitely* on the TODO list
so we can avoid multiple kernel images.
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<
On Tue, 2020-06-23 at 16:37 -0400, Jonathan Behrens wrote:
On Fri, Jun 19, 2020 at 5:42 PM Atish Patra <
On Jun 19, 2020, at 1:26 PM, Jonathan Behrens <
Thanks for that clarification! It is good to know that
implementations are consistent about returning negative
for functions they don't recognize like
This however doesn't work for environments which cannot
want to implement the SBI at all (what value do you
there is no SBI?)
Once RISC-V is more widely deployed, it is likely that
be more platform specs written by other committees, or
groups entirely outside of the RISC-V foundation. They
want to require ecalls to detect capabilities, or might
other constraints. Yet, developers will likely want to
kernels that can boot across a range of these different
environments. This has certainly been the case on x86
there's lots of different bootloaders that each work with
own conventions.Yes. That’s a possibility. If I understand you correctly,
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
instead of reserving a register for a fixed value.The register value would also signal the other elements of
platform spec are being followed. Notably including that a1actually
points to a valid device tree. If we could count on a device
always being present then I agree that going the /chosen
be cleaner, but if a future third party standard decided to
ACPI tables or something instead then they may not be willing
require a dummy device tree just to allow software to blindlyFor ACPI tables, a similar property can be added in the ACPI
We anyways have to add other run time properties to ACPI table
currently for the device tree.
To give one case where this already seems to be coming
can run in M-mode instead of S-mode but only if it is
that way at compile time. If Linux had a better way to
whether there was firmware present, it might be able to
shared kernel binary for both cases.
On Wed, Jun 17, 2020 at 2:56 PM Atish Patra <
On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens
To start off discussion about requirements that
platform spec, I propose a simple change to current
When entering S-mode for the first time, the a2
contain the value 0x54414c5058494e55 ("UNIXPLAT").
The intention here is that software should be able to
value and know that it has been booted in a
Environment that is compliant with the Unix-class
would distinguish both from old implementations that
v0.1, but also possible future execution environmentsdesigned by
other groups.For SBI version, supervisor systems should use
API to identify what is the SBI version of the SBI
v0.1, the above call will return a -ve value indicating
this is a
That's how linux kernel currently detects the SBI
Red Hat, Inc.