On Mon, 2021-04-26 at 12:56 +0530, Mayuresh Chitale wrote:
On Sun, Apr 25, 2021 at 2:55 AM Heinrich Schuchardt <
Am 24. April 2021 20:37:58 MESZ schrieb Sean Anderson
On 4/11/21 11:02 AM, Mayuresh Chitale wrote:with
This patch is an initial draft for the sectioninitial platform
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-
index 003181c..f164545 100644
@@ -52,10 +52,33 @@ include::profiles.adoc
* Interrupt Assignments
==== System Peripherals
-* UART/Serial Console
-* Watchdog Timers
+* *UART/Serial Console* +
+In order to facilitate the bringup and debug of the low level
+software(firmware, bootloaders, kernel etc), the platformimplement a UART
+port compatible with PC16550D.
+* *Clock and Timers* +
+** Platforms shall provide a 10ns resolution 64-bit counter
strictly monotonic updates.
+** The counter shall have a minimum update frequency of 10MHz.
+** Platforms shall implement the time CSR.
In order to allow the existing hardware to comply with the Linux2022
spec, we should add additional clarification.
It is recommended that platforms shall implement the time CSR. In
absence of time CSR, the M-mode software must emulate the time CSR read
by trapping the access. The software emulation approach is deprecated
and will be removed in the next version of the specification.
+** Platforms shall advertise the timebase to the operating
+`timebase-frequency` DT property.This is the first mention of DT AFAICT, so we should clarify
comes from and what the relevant specifications are. Should wewait to
use whatever  standardizes on? Will we need to be forward-compatible
in this regard? is about saving configuration data in the SoC. It is not about
the format in which the data is presented by the firmware.
But mentioning a DT property without a node and a format is
insufficient. If this is defined somewhere else, we need a
This property is defined in the cpus node for riscv:
. We can refer to this in the platform spec.
The larger objective of the platform spec is to serve all the Rich-OS
(Linux/FreeBSD/Windows) in future. That's why, we shouldn't point to
any Linux specific DT bindings from platform spec.
How about rewording it in a way that it is agnostic to OS ?
Platforms shall advertise the timebase to the operating systems via the
appropriate hardware discovery method.
+** Platforms shall implement theextension.
+** Platforms shall delegate the supervisor timer interrupt to
mode and ifvalue
+the 'H' extension is implemented, the virtual supervisor timerinterrupt to 'VS' mode.
+* Watchdog Timers +
+** Platforms shall implement a two stage watchdog timer.
+** The software shall periodically update the watchdog stage 1
+** If the mtime/time increments past the watchdog stage 1
value then ancompare
+interrupt shall be raised and routed to a RISC V hart and thewatchdog stage 2
+shall be activated.
+** If the mtime/time increments past the watchdog stage 2
+interrupt shall be raised and routed to an external hardware
such as avalue
+BMC to affect a system reset. If the watchdog stage1 compare
+before such an event occurred then the watchdog stage 1
+deasserted and the watchdog stage 2 shall be deactivated.
==== Boot Process