Jonathan Behrens <behrensj@...>
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? 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? 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.
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
|
