Re: [PATCH v1 2/2] Section 3.1.4 System Peripherals.


atishp@...
 

On Tue, 2021-04-27 at 23:59 -0400, Jonathan Behrens wrote:


On Tue, Apr 27, 2021 at 11:37 PM Atish Patra <Atish.Patra@...>
wrote:
On Tue, 2021-04-27 at 22:13 -0400, Jonathan Behrens wrote:
Platforms shall advertise the timebase to the operating systems
via
the appropriate hardware discovery method.

Isn't one of the main points of these platform specs to specify
the
details of how platforms communicate information (like the
timebase)
to operating systems?
Yes. But specifying an approach that is very specific to Linux may
not
work with other OS. In this case, "timebase-frequency" DT property
is
specific to Linux. Other OS may or may not adopt the same name for
the
timebase. Moreover, it will be a different property for ACPI
(server
extension).

I'm confused by this. If we specify that the frequency is
communicated via the "timebase-frequency" DT property, then all
operating systems will know to look for that. My mental model is that
OS writers will read this platform spec, and then using their
understanding they will write software to interpret the information
provided by the platform at initialization time. Am I
misunderstanding?
You are correct. If the platform spec defines the dt binding in details
for the timebase frequency, all other OS may simply just implement it.

Here are my concerns with this approach.

1. If the platform spec just defines the DT binding for everything, the
spec may blow up.

1. The current DT bindings are reviewed/approved by the Linux kernel
community. As Henerich mentioned, it may not sufficient in every case.

If we can address these concerns in the platform specs, it would be
great.


That's why, I suggested to keep it generic so that platforms know
they
must communicate timebase information via ACPI/DT.

It seems useless to specify "communicate via ACPI/DT" without saying
how the information would be encoded.

On Tue, Apr 27, 2021 at 7:52 PM Atish Patra via lists.riscv.org <
atish.patra=wdc.com@...> wrote:
On Mon, 2021-04-26 at 12:56 +0530, Mayuresh Chitale wrote:


On Sun, Apr 25, 2021 at 2:55 AM Heinrich Schuchardt <
xypron.glpk@...> wrote:
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.
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
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.

This property is defined in the cpus node for riscv: 
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/riscv/cpus.yaml
. 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.

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


 
--
Regards,
Atish

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