> -----Original Message-----
> From: tech-unixplatformspec@... <tech-
> unixplatformspec@...> On Behalf Of Atish Patra
> Sent: 28 April 2021 09:07
> To: behrensj@...
> Cc: xypron.glpk@...; tech-unixplatformspec@...;
> seanga2@...; mchitale@...
> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v1 2/2] Section 3.1.4
> System Peripherals.
>
> 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).
>
> That's why, I suggested to keep it generic so that platforms know they must
> communicate timebase information via ACPI/DT.

This is not entirely true. The DT bindings defined in Linux sources are a
standard and should be followed by all operating systems. This means
other OSes (BSD, VxWorks, etc) will have to look for "timebase-frequency"
DT property. Unfortunately, the DT bindings are still part of Linux sources
and not hosted as

I think it is good to clearly mention that if hardware configuration is
based on DT then where to look for timer frequency. Eventually, this
will also add details of ACPI.

The RISC-V hardware configuration structure is not suitable for this
purpose because DT and ACPI are widely adopted methods by
various OSes so we should stick to these. The RISC-V hardware
configuration structure can be used for other purposes such as
debugger or low-level firmware.

Regards,
Anup

>
> > 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/devicet
> > > ree/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
>
>
>
>