It seems like the watchdog description belongs in a separate specification that either describes the register memory layout, or else as a RISC-V ISA extension that lists the CSRs to control it. The current description in the text doesn't seem to have enough detail for software to actually use it.

Jonathan

On Fri, Apr 23, 2021 at 9:36 AM Mayuresh Chitale via lists.riscv.org <mchitale=ventanamicro.com@...> wrote:

On Fri, Apr 23, 2021 at 6:23 AM Abner Chang <renba.chang@...> wrote:

Atish Patra <atish.patra@...> 於 2021年4月23日 週五 上午7:49寫道：

On Sun, 2021-04-11 at 20:32 +0530, Mayuresh Chitale wrote:
> This patch is an initial draft for the section
> 3.1.4 - System Peripherals.
>
> Signed-off-by: Mayuresh Chitale <mchitale@...>
> ---
>  riscv-platform-spec.adoc | 31 +++++++++++++++++++++++++++----
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 003181c..f164545 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -52,10 +52,33 @@ include::profiles.adoc[]
>  * Interrupt Assignments
>  
>  ==== System Peripherals
> -* UART/Serial Console
> -* Clocks
> -* Timers
> -* Watchdog Timers
> +* *UART/Serial Console* +
> +In order to facilitate the bringup and debug of the low level
> initial platform
> +software(firmware, bootloaders, kernel etc), the platform shall
> implement a UART
> +port compatible with PC16550D.
> +* *Clock and Timers* +
> +** Platforms shall provide a 10ns resolution 64-bit counter with
> strictly monotonic updates.
> +** The counter shall have a minimum update frequency of 10MHz.
> +** Platforms shall implement the time CSR.
> +** Platforms shall advertise the timebase to the operating systems
> via the
> +`timebase-frequency` DT property.
> +** Platforms shall implement the
> +https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extensio
> n.
> +** Platforms shall delegate the supervisor timer interrupt to 'S'
> mode and if
> +the 'H' extension is implemented, the virtual supervisor timer
> interrupt to 'VS' mode.
> +
> +* Watchdog Timers +
> +** Platforms shall implement a two stage watchdog timer.

As the base specification also targets the dev boards, academia FPGAs
at least for Linux 2022, do we need to mandate a watchdog timer.

May be put it as strongly recommended and mandate it in Linux 2024
specification ?

> +** The software shall periodically update the watchdog stage 1 value
> to a
> +future moment.
> +** If the mtime/time increments past the watchdog stage 1 compare
> value then an
> +interrupt shall be raised and routed to a RISC V hart and the
> watchdog stage 2
> +shall be activated.
> +** If the mtime/time increments past the watchdog stage 2 compare
> value an
> +interrupt shall be raised and routed to an external hardware unit
> such as a
> +BMC to affect a system reset. 

Should we have to define the implementation when the watchdog stage 2 is timeout?

How to handle the timeout should be platform design specific (the HW could be BMC on server or EC on laptop). It is also firmware implementation specifc, system FW or BMC FW may do something else before resetting the system.

Is the below statement sufficient?

"If the mtime/time increments past the watchdog stage 2 compare value an interrupt shall be raised for the further actions."

We can rephrase it to "If the mtime/time increments past the watchdog stage 2 compare value then a system reset shall occur". This leaves open the question of how and when the reset will occur while requiring that the reset must occur.

Regards,

Abner

Is it only intended for server extension as BMCs are common in servers
? We may need to clarify what happens in absence of a BMC ?

> If the watchdog stage1 compare value was updated
> +before such an event occurred then the watchdog stage 1 interrupt
> shall be
> +deasserted and the watchdog stage 2 shall be deactivated.
>  
>  ==== Boot Process
>  * Firmware

--
Regards,
Atish