1. Messages
  2. Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

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

Greg Favor
 

On Thu, Jun 4, 2020 at 11:45 PM Atish Patra <atish.patra@...> wrote:
> 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 ?

Yes, I imagine so.  Eventually this would be desirable as a very basic form of RAS, i.e when the system is hung or in livelock, this would bring control back to system firmware (to log, recover, reboot, etc.).


> Standard system UART for early boot communication.
>

Do we have to say which standard UART ?

This is desirable for the sake of early boot software (before it's convenient to be loading in platform-specific drivers).  (As a side-note, when ARM SBSA first mandated this, it painfully blew it by not standardizing a little detail like the clock frequency for the UART.)

In any case, this and surrounding comments are about standardizing basics of the platform that provide no differentiation value and just complicate life when one wants to get to a world where one can take a compliant platform, install standard binaries, and have it all work out of the box.  Not an issue for embedded systems, but certainly important if and when RISC-V is going to get into parts of the server or edge compute space.
 
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?

In embedded systems, probably.  But, as noted above, desirable on standardized server-class systems (even if going into high-end embedded "infrastructure" type systems - which are increasingly looking more like Linux servers platforms and less like classic embedded Linux systems).
 

> 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.

Hopefully this suggestion makes more sense given my comments above.  Not necessary for embedded systems, but very desirable for high-end embedded and server-class systems (as ARM took a long time to realize).

Greg
Join {tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.