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] extension.
+** 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.
+** 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. 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
--
2.17.1

On 4/11/21 5:02 PM, 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.

Is software compatibility with PC16550D free of copyright restrictions?
(We should not disallow open hardware.)

Strict PC16550D compatibility would for instance preclude usage of lower
voltages. Is this really needed?

Isn't it enough to to have any UART that at least supports 115200,8N1?

Best regards

Heinrich

+* *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] extension.
+** 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.
+** 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. 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

On Sun, 2021-04-11 at 12:22 -0400, Jonathan Behrens wrote:

On Sun, Apr 11, 2021 at 11:46 AM Heinrich Schuchardt via
lists.riscv.org <xypron.glpk=gmx.de@...> wrote:

On 4/11/21 5:02 PM, 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.

Is software compatibility with PC16550D free of copyright
restrictions?
(We should not disallow open hardware.)

Strict PC16550D compatibility would for instance preclude usage of
lower
voltages. Is this really needed?

Isn't it enough to to have any UART that at least supports
115200,8N1?

For software, it very much matters that the register layout and
behavior match some standard. Otherwise you would need to ship
drivers for essentially every uart ever made (which might be
acceptable to Linux because it already has them, but would be wasted
effort for anyone else). 

Isn't this the Linux and other Rich OS spec though?

Alistair

That said, this spec shouldn’t be specifying the physical
implementation of the uart. It should be allowed to use a
real PC16550D, a lower voltage one, a uart tunneled over Ethernet, or
even an entirely emulated uart (say for  a VM).

Jonathan

For software, it very much matters that the register layout and
behavior match some standard. Otherwise you would need to ship
drivers for essentially every uart ever made (which might be
acceptable to Linux because it already has them, but would be wasted
effort for anyone else). 

Isn't this the Linux and other Rich OS spec though?

It's usually the early boot environment that's the key issue for the UART, rather than the kernel.  Early boot is space-constrained and generally doesn't have good device data, so just aligning on some well-known base address and hardware register interface makes life a lot easier.

- Paul

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. 

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

On Thu, 2021-04-22 at 17:02 -0700, Greg Favor wrote:

On Thu, Apr 22, 2021 at 4:49 PM Atish Patra <atish.patra@...>
wrote:

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

Are dev boards / academic FPGA implementations going to care about
being able to brand themselves as Linux-2022 compliant?  

Probably some of them are. At least I know OpenPiton guys are
interested because they can just run upstream software stack without
worrying too much.

And should we let the tail wag the dog in defining a platform spec
for production systems?  They could just disable the software
watchdog functionality (along with whatever other disables for other
shortcuts that were made).
 

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

Or does there need to be a "Minimal" platform spec with even fewer
requirements than the Base spec - just for the above sort of
designs.  It seems like watering down the Base spec is a disservice
to industrial-class production embedded Linux systems.

As per my understanding, Linux2022 base is the minimal spec which makes
the existing boards (HiFive unleashed/unmatched/beagleV) automatically
compliant with Linux2022 base.

That's also one of the reasons why we are persisting with PLIC/CLINT in
Linux2022. But it is marked as deprecated so that future platforms
don't persists with old hardware IPs in future.

Greg


 

--
Regards,
Atish

On 4/11/21 11:02 AM, 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.

This is the first mention of DT AFAICT, so we should clarify where it
comes from and what the relevant specifications are. Should we wait to
use whatever [1] standardizes on? Will we need to be forward-compatible
in this regard?

--Sean

[1] https://github.com/riscv/configuration-structure

+** Platforms shall implement the
+https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension.
+** 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.
+** 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. 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

Am 24. April 2021 20:37:58 MESZ schrieb Sean Anderson <seanga2@...>:

On 4/11/21 11:02 AM, 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.

This is the first mention of DT AFAICT, so we should clarify where it
comes from and what the relevant specifications are. Should we wait to
use whatever [1] standardizes on? Will we need to be forward-compatible
in this regard?

--Sean

[1] https://github.com/riscv/configuration-structure

[1] 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 reference.

Best regards

Heinrich

+** Platforms shall implement the
+https://lists.riscv.org/g/tech-privileged/message/404[Sstc]

extension.

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