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