On Tue, 2020-06-02 at 19:32 -0700, Greg Favor wrote:

One additional topic: All the various architecture specs have little
to lots of optional features or parameters that can be
implementation-specific. Some of these probably want to have minimum
requirements specified in the Linux platform spec (similar to what
the ARM SBSA does, for example). For example:

A minimum reservation set size for LR/SC.

Minimum supported ASID size.

Minimum number and width of hardware performance counters. Support
for the small set of standard Linux perf mon events.

If the Hypervisor extension is supported:
Minimum supported VMID size
Full support for CSR's like htval and htinst

Past RV64GC, what other extensions should be required? For example,
the BitManip Zba/Zbb/Zbs extensions (and maybe Zbc) have value for
general compiled code? In the future the hypervisor and vector
extensions probably want to become a requirement (but as say part of
a future next "level" of platform spec).

As discussed, RV64GC should be the minimum required extensions to boot
Linux.

Minimum and recommended mtime frequency.

Sure. I think most of the above should be specified in the
specification. I am hoping somebody will send a PR now :-):-).

Standard system watchdog timer?

AFAIK, we don't have any system watchdog timer in any of the current
RISC-V hardware. May be we can defer this ?

Standard system UART for early boot communication.

Do we have to say which standard UART ?
An uart must be available but the implementation details doesn't need
go into the platform spec.

The Debug spec (which provides facilities for self-hosted as well as
external debug) has most features as optional. At least for self-
hosted debug purposes, should there be a minimum set of trigger
module requirements for how many triggers and what trigger features
are available?

Is it a common practice to mandate a subset of debug spec in a platform
specification?

Presenting on-chip peripherals as PCIe integrated endpoints? (SBSA
provides a lot of standardization along these lines. But this may be
a bridge too far at this early stage of platform standardization.)

I guess so.

Greg

On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...>
wrote:

Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than
it
currently has :)

Here are some suggestions. This is just a small list that I can
think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
- S-mode CSR state before entering to S-mode
- GPR state before entering to S-mode (e.g a0 must contain

hartid, a1 must contain DT address)

2. Runtime firmware requirement:
- Platform runtime firmware must implement SBI v0.2

specification. We can avoid legacy implementations in future
if we
make this mandatory now. But, I am open to other
suggestions
as well.
- RISC-V ISA allows hardware not to implement misaligned

load/store. platform runtime firmware must implement it if it

is not implemented in hardware.
- TIME csr emulation support if not implemented in HW
- HTIMEDELTA csr emulation support (for platforms with
hypervisor support)
- This section can link to the SBI specification.

3. Memory requirement
- DRAM start address
- memory model supported
- Boot address alignment requirement (2MB/4MB for
64bit/32bit)
- other requirement ?

4. Interrupt requirement
- What should be PLIC state upon entering S-mdoe
- Can link to the PLIC specifications
- local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue
that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM
PST.

FYI: The meeting webex link is available in calendar. Let me know
if
you have any issues accessing that.

--
Regards,
Atish