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
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@...>
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
make this mandatory now. But, I am open to other
- 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
- 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.