Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))


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

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

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.


On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...>
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

Here is the current version if unix platform specification.

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

Here are some suggestions. This is just a small list that I can
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
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
- 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
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM

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


Join to automatically receive all group messages.