Date   

Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Anup Patel
 

Hi Abner,

 

I agree with your points 1) to 3).

 

Regards,

Anup

 

From: Abner Chang <renba.chang@...>
Sent: 25 May 2021 13:46
To: Anup Patel <Anup.Patel@...>
Cc: Alistair Francis <Alistair.Francis@...>; sunilvl@...; tech-unixplatformspec@...; mchitale@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

 

 

 

Anup Patel <Anup.Patel@...> 2021525 週二 下午12:39寫道:

Hi Alistar,

> -----Original Message-----
> From: tech-unixplatformspec@... <tech-
> unixplatformspec@...> On Behalf Of Alistair Francis
> Sent: 24 May 2021 12:54
> To: renba.chang@...
> Cc: sunilvl@...; tech-unixplatformspec@...;
> mchitale@...
> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-
> spec: PLIC and CLINT for Linux-2022 platform
>
> On Mon, 2021-05-24 at 14:52 +0800, Abner Chang wrote:
> >
> >
> > Alistair Francis <Alistair.Francis@...> 2021524 週一
> > 上午11:42寫道:
> > > On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> > > > From: Abner Chang <renba.chang@...>
> > > >
> > > > Initial description of PLIC  CLINT section of Linux-2022 platform.
> > > >
> > > > Is this what we want to see of CLINT/Machine mode timer in the
> > > > platform spec?
> > > >
> > > > On v4 commit,
> > > > - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> > > > - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> > > > mention
> > > >   IPI because AIA already supported it.
> > > > - In Embedded-2022 Machine mode timer section, CLINT is not
> > > > mandatory.
> > > > - Separate section in appendix for the Machine mode timer
> > > > registers
> > > >
> > > > On v3 commit,
> > > > - Address review comments.
> > > >
> > > > On v2 commit,
> > > > - CLINT is not deprecated.
> > > >
> > > > - Add a standalone section for Machine Mode Timer in System
> > > > Peripherals.
> > > >   Do you think this is a good place for Machine Mode Timer?
> > > >   @Mayuresh, please check if you are ok with this change, not sure
> > > if
> > > > this
> > > >   overlaps with your text or not (The timer setion). I can remove
> > > > this
> > > >   if you prefer to put this with your patch.
> > > >
> > > > - In Embedded-2022, refer to Machine Mode Timer in System
> > > Peripherals
> > > >   section and CLINT in Linux-2022 Platform.
> > > >   @Alistair, is this ok?
> > > >
> > > > On v1 commit,
> > > > - Not sure where to put the [DEPRECATED].
> > > > - Change the reference of PLIC in section 2.2.2. Interrupt
> > > Controller
> > > > to
> > > >   1.1.3.2 PLIC + CLINT section.
> > > >
> > > > Signed-off-by: Abner Chang <renba.chang@...>
> > > > Cc: Alistair Francis <alistair.francis@...>
> > > > Cc: Sunil V L <sunilvl@...>
> > > > Cc: Mayuresh Chitale <mchitale@...>
> > > > ---
> > > >  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
> > > > --
> > > --
> > > > --
> > > >  1 file changed, 62 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > > > index 160c74a..f8838ab 100644
> > > > --- a/riscv-platform-spec.adoc
> > > > +++ b/riscv-platform-spec.adoc
> > > > @@ -49,15 +49,37 @@ include::profiles.adoc[]
> > > >  * Start Address
> > > >
> > > >  ==== Interrupt Controller
> > > > -* AIA
> > > > -* PLIC + CLINT
> > > > -* Interrupt Assignments
> > > > +===== AIA[[AIA]]
> > > > +===== PLIC[DEPRECATED][[PLIC]]
> > > > +The Platform Level Interrupt Controller (PLIC) provides
> > > > facilities
> > > > to route
> > > > +the non-local interrupts to the external interrupt of a hart
> > > context
> > > > +with a given privilege mode in a given hart. The number of non-
> > > local
> > > > interrupt
> > > > +sources supported by PLIC and how does each of them connect to
> > > > the
> > > > hart
> > > > +context is PLIC core implementation-specific. + (Refer to
> > > >
> > > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc
> > > [RISC-V
> > > >  PLIC Specification]
> > > > +for the implementation reference of PLIC operation parameters)
> > > > +
> > > > +===== CLINT[[CLINT]]
> > > > +On the contrast to PLIC, the Core Local Interrupt (CLINT)
> > > > provides
> > >
> > > I don't think this is a contrast to the PLIC, it's just a different
> > > functionality.
> > >
> >
> > Can rephase it.
> > >
> > > I'm also not sure the CLINT should be in the interrupt controller
> > > section. It is the Core Local INTerruptor (CLINT), not an interrupt
> > > controller.
> > >
> >
> > Hmm.. CLINT is not a sort of interrupt controller but seems to me it
> > is unnecessary to create another section apart from the Interrupt
> > Controller section.
>
> It probably makes more sense to add a timer section and put the CLNIT there
> instead of forcing it into the interrupt controller section, when it isn't really an
> interrupt controller.
>
> > >
> > > > +facilities to trigger local interrupt of
> > > <<MachineModeTimer,Machine
> > > > mode timer>> to hart.
> > > > +
> > > > +===== Interrupt Assignments
> > > >
> > > >  ==== System Peripherals
> > > > -* UART/Serial Console
> > > > -* Clocks
> > > > -* Timers
> > > > -* Watchdog Timers
> > > > +===== UART/Serial Console
> > > > +===== Clocks
> > > > +===== Timers
> > > > +
> > > > +===== Machine Mode Timer[[MachineModeTimer]] Machine mode
> timer
> > > > +is required for Linux-2022 platform and
> > > > incorporate with
> > > > +<<CLINT,CLINT>> to trigger the timer event to hart. The format
> > > > of
> > > > Machine mode timer operation parameters
> > > > +(`mtime` and `mtimecmp` registers) must compliant with RISC-V
> > >
> > > s/must compliant/must be compliant/g
> > >
> >
> > will correct this
> > >
> > > > Privilege specification section 3.1.10.
> > > > +The base address of the memory map registers of Machine mode
> > > > timer
> > > > is platform implementation-specific,
> > > > +however the offset of `mtime` and `mtimecmp` registers are fixed
> > > as
> > > > +<<machineModeTimerRegs,Machine mode timer registers>>.
> > > > +
> > > > +
> > > > +===== Watchdog Timers
> > > >
> > > >  ==== Boot Process
> > > >  * Firmware
> > > > @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
> > > can
> > > > meet the Embedded-2022
> > > >  specification.
> > > >
> > > >  ==== Interrupt Controller
> > > > -Embedded systems are recommended to use a spec compliant
> > > > -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> > > > -
> > > >
> > > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[
> > > CLIC]
> > > > +Embedded systems are recommended to use a spec compliant
> > > > <<PLIC,PLIC>>, a spec
> > > > +compliant
> > > >
> > > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[
> > > CLIC]
> > > >  or both a CLIC and and PLIC.
> > > >
> > > >  If using just a PLIC the system must continue to use the original
> > > > basic @@ -303,38 +324,9 @@ must be supported.
> > > >  Embedded systems cannot use a non-compliant interrupt controller
> > > and
> > > > still
> > > >  call it a PLIC or CLIC.
> > > >
> > > > -==== Machine Timer
> > > > -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> > > > must be -implemented. The two registers must be memory mapped as
> > > > required
> > > by
> > > > the RISC-V
> > > > -specification.
> > > > -
> > > > -The Embedded-2022 specification requires that the registers be
> > > > mapped -adjacent to each other with the `mtime` region at the
> > > > lower
> > > address.
> > > > -
> > > > -The starting address of this region can be located anywhere in
> > > > -memory, including inside other peripherals, as long as the start
> > > > address is
> > > > -4 byte aligned.
> > > > -
> > > > -An example of the memory layout for a 32-bit system with a single
> > > > hart is below
> > > > -
> > > > --------------------------
> > > > -=========================
> > > > -| 0x00 |  mtime low     |
> > > > -| 0x04 |  mtime high    |
> > > > -| 0x08 |  mtimecmp low  |
> > > > -| 0x0C |  mtimecmp high |
> > > > -=========================
> > > > --------------------------
> > > > -
> > > > -and for a 64-bit system with 2 harts
> > > > -
> > > > ----------------------------
> > > > -===========================
> > > > -| 0x00 |  mtime           |
> > > > -| 0x08 |  mtimecmp hart 1 |
> > > > -| 0x10 |  mtimecmp hart 2 |
> > > > -===========================
> > > > ----------------------------
> > > > +==== Machine Mode Timer
> > > > +The Embedded-2022 specification requires RISC-V
> > > > <<MachineModeTimer,Machine mode timer>> to be implemented.
> > > > +The Machine mode timer could be incorporated with the Core Local
> > > > Interrupt (<<CLINT, CLINT>>) or the specific event trigger
> > > mechanism
> > >
> > > CLINT is INTerruptor not just Interrupt.
> > >
> >
> > yes, will correct it
> > >
> > > > according to the platform design.
> > >
> > > What specific trigger mechanism?
> > >
> >
> > platform implementation-specific trigger mechanism?  or just remove
>
> I meant you didn't say what the mechanism is. It should be explicit, so that
> there are no ambiguities.
>
> > this? I put this just because the previous feedback says a small
> > system may not have CLINT for the m-mode timer.
>
> I would be in favour of saying either do what we already have written here OR
> a CLINT.
>
> If we go with something else that's ok, we just need to be clear about what it
> is.
>
> > >
> > > >
> > > >  ==== Memory Map
> > > >  It is recommended that main memory and loadable code (not ROM)
> > > start
> > > > at
> > > > @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> > > > include at least 4 regions, although
> > > >  if possible more should be supported to allow more flexibility.
> > > > Hardware
> > > >  implementations should aim for supporting at least 16 PMP
> > > > regions.
> > > >
> > > > +// Appendix sections
> > > > +== Appendix
> > > > +=== Machine Mode Timer Registers [[MachineModeTimerRegs]] The
> > > > +base address of Machine mode timer operation parameters is
> > > > platform implementation-specific. The Machine mode timer compare
> > > > registers (`mtimecmp`) for each hart is located at offset 0 and
> > > > the layout is organized as below table.
> > >
> > > Can we maintain what we have for the embedded spec?
> > >
> >
> > Do you mean to maintain the register layout(offset) originally defined
> > in the 2.2.3. for embedded systems?
>
> Yes. I worry that mandating a CLINT layout is too restrictive and that no one
> will end up following the embedded-2022 spec then. I would be in favour of
> saying CLINT or the memory layout we already have.

The ACLINT spec does not enforce any memory layout.
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

The ACLINT is backward compatible to CLINT we should refer ACLINT
in-place of CLINT. This gives platform vendors flexibility to choose
their or memory layout and implement only certain parts of ACLINT
as required.

 

Hi Anup and Alistair. 

With ACLINT spec defined, I think we can revise this patch as below,

1.Remove CLINT from platform spec

2 Mention ACLINT in platform spec for Linux2020 platform and have a link to https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc.

3. Remove Machine mode timer from system peripheral because that is in the scope of ACLINT

4. For Embedded-2022 platform, mention Machine mode timer and refer to ACLINT for the definition of registers.

Any other thoughts?

 

Abner

 


Regards,
Anup

>
> > I think we have the register layout as below to be compliant with the
> > m-mode timer registers defined in SiFive CLINT.
>
> I don't think that's flexible enough and that vendors won't want to follow it as
> they already have other IP they are using for timers.
>
> Alistair
>
> > Or do you mean something else?
> >
> > >  It allows the
> > > memory maps to be inside of a MMIO device. For example they can be
> > > registers inside of a general system controller.
> > >
> > >
> > > Also it looks like the lines are a little long here, can be bring
> > > them back to 80 charecters?
> > >
> >
> > sure.
> > >
> > > > +
> > > > +.Registers layout of mtimecmp
> > > > +[width="60%",cols="1,^3,^3"]
> > > > +|=======
> > > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > > RV32*
> > > > +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > > > +|`0x0004` ||mtimecmp high for hart 0
> > > > +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > > > +|`0x000c` ||mtimecmp high for hart 1
> > > > +|... ||
> > > > +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > > > +|`0x7ff4` ||mtimecmp high for hart 4094
> > > > +|=======
> > > > +
> > > > +The Machine mode timer counter (`mtime`) is located at offset
> > > 0x7ff8
> > > > from the base address of operation parameters.
> > > > +
> > > > +.Registers layout of mtime
> > > > +[width="60%",cols="1,^3,^3"]
> > > > +|=======
> > > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > > RV32*
> > > > +|`0x7ff8` |mtime|mtime low
> > > > +|`0x7ffc` ||mtime high
> > > > +|=======
> > >
> > > Are you saying for a small embedded single core CPU we need to put
> > > mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
> > > addresses between them?
> > >
> > > Alistair
> > >
> > > > +
> > > >  // acknowledge all of the contributors
> > > >  include::contributors.adoc[]
> > >
>
>
>
>
>


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Abner Chang
 



Anup Patel <Anup.Patel@...> 於 2021年5月25日 週二 下午12:39寫道:
Hi Alistar,

> -----Original Message-----
> From: tech-unixplatformspec@... <tech-
> unixplatformspec@...> On Behalf Of Alistair Francis
> Sent: 24 May 2021 12:54
> To: renba.chang@...
> Cc: sunilvl@...; tech-unixplatformspec@...;
> mchitale@...
> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-
> spec: PLIC and CLINT for Linux-2022 platform
>
> On Mon, 2021-05-24 at 14:52 +0800, Abner Chang wrote:
> >
> >
> > Alistair Francis <Alistair.Francis@...> 於 2021年5月24日 週一
> > 上午11:42寫道:
> > > On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> > > > From: Abner Chang <renba.chang@...>
> > > >
> > > > Initial description of PLIC  CLINT section of Linux-2022 platform.
> > > >
> > > > Is this what we want to see of CLINT/Machine mode timer in the
> > > > platform spec?
> > > >
> > > > On v4 commit,
> > > > - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> > > > - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> > > > mention
> > > >   IPI because AIA already supported it.
> > > > - In Embedded-2022 Machine mode timer section, CLINT is not
> > > > mandatory.
> > > > - Separate section in appendix for the Machine mode timer
> > > > registers
> > > >
> > > > On v3 commit,
> > > > - Address review comments.
> > > >
> > > > On v2 commit,
> > > > - CLINT is not deprecated.
> > > >
> > > > - Add a standalone section for Machine Mode Timer in System
> > > > Peripherals.
> > > >   Do you think this is a good place for Machine Mode Timer?
> > > >   @Mayuresh, please check if you are ok with this change, not sure
> > > if
> > > > this
> > > >   overlaps with your text or not (The timer setion). I can remove
> > > > this
> > > >   if you prefer to put this with your patch.
> > > >
> > > > - In Embedded-2022, refer to Machine Mode Timer in System
> > > Peripherals
> > > >   section and CLINT in Linux-2022 Platform.
> > > >   @Alistair, is this ok?
> > > >
> > > > On v1 commit,
> > > > - Not sure where to put the [DEPRECATED].
> > > > - Change the reference of PLIC in section 2.2.2. Interrupt
> > > Controller
> > > > to
> > > >   1.1.3.2 PLIC + CLINT section.
> > > >
> > > > Signed-off-by: Abner Chang <renba.chang@...>
> > > > Cc: Alistair Francis <alistair.francis@...>
> > > > Cc: Sunil V L <sunilvl@...>
> > > > Cc: Mayuresh Chitale <mchitale@...>
> > > > ---
> > > >  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
> > > > --
> > > --
> > > > --
> > > >  1 file changed, 62 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > > > index 160c74a..f8838ab 100644
> > > > --- a/riscv-platform-spec.adoc
> > > > +++ b/riscv-platform-spec.adoc
> > > > @@ -49,15 +49,37 @@ include::profiles.adoc[]
> > > >  * Start Address
> > > >
> > > >  ==== Interrupt Controller
> > > > -* AIA
> > > > -* PLIC + CLINT
> > > > -* Interrupt Assignments
> > > > +===== AIA[[AIA]]
> > > > +===== PLIC[DEPRECATED][[PLIC]]
> > > > +The Platform Level Interrupt Controller (PLIC) provides
> > > > facilities
> > > > to route
> > > > +the non-local interrupts to the external interrupt of a hart
> > > context
> > > > +with a given privilege mode in a given hart. The number of non-
> > > local
> > > > interrupt
> > > > +sources supported by PLIC and how does each of them connect to
> > > > the
> > > > hart
> > > > +context is PLIC core implementation-specific. + (Refer to
> > > >
> > > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc
> > > [RISC-V
> > > >  PLIC Specification]
> > > > +for the implementation reference of PLIC operation parameters)
> > > > +
> > > > +===== CLINT[[CLINT]]
> > > > +On the contrast to PLIC, the Core Local Interrupt (CLINT)
> > > > provides
> > >
> > > I don't think this is a contrast to the PLIC, it's just a different
> > > functionality.
> > >
> >
> > Can rephase it.
> > >
> > > I'm also not sure the CLINT should be in the interrupt controller
> > > section. It is the Core Local INTerruptor (CLINT), not an interrupt
> > > controller.
> > >
> >
> > Hmm.. CLINT is not a sort of interrupt controller but seems to me it
> > is unnecessary to create another section apart from the Interrupt
> > Controller section.
>
> It probably makes more sense to add a timer section and put the CLNIT there
> instead of forcing it into the interrupt controller section, when it isn't really an
> interrupt controller.
>
> > >
> > > > +facilities to trigger local interrupt of
> > > <<MachineModeTimer,Machine
> > > > mode timer>> to hart.
> > > > +
> > > > +===== Interrupt Assignments
> > > >
> > > >  ==== System Peripherals
> > > > -* UART/Serial Console
> > > > -* Clocks
> > > > -* Timers
> > > > -* Watchdog Timers
> > > > +===== UART/Serial Console
> > > > +===== Clocks
> > > > +===== Timers
> > > > +
> > > > +===== Machine Mode Timer[[MachineModeTimer]] Machine mode
> timer
> > > > +is required for Linux-2022 platform and
> > > > incorporate with
> > > > +<<CLINT,CLINT>> to trigger the timer event to hart. The format
> > > > of
> > > > Machine mode timer operation parameters
> > > > +(`mtime` and `mtimecmp` registers) must compliant with RISC-V
> > >
> > > s/must compliant/must be compliant/g
> > >
> >
> > will correct this
> > >
> > > > Privilege specification section 3.1.10.
> > > > +The base address of the memory map registers of Machine mode
> > > > timer
> > > > is platform implementation-specific,
> > > > +however the offset of `mtime` and `mtimecmp` registers are fixed
> > > as
> > > > +<<machineModeTimerRegs,Machine mode timer registers>>.
> > > > +
> > > > +
> > > > +===== Watchdog Timers
> > > >
> > > >  ==== Boot Process
> > > >  * Firmware
> > > > @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
> > > can
> > > > meet the Embedded-2022
> > > >  specification.
> > > >
> > > >  ==== Interrupt Controller
> > > > -Embedded systems are recommended to use a spec compliant
> > > > -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> > > > -
> > > >
> > > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[
> > > CLIC]
> > > > +Embedded systems are recommended to use a spec compliant
> > > > <<PLIC,PLIC>>, a spec
> > > > +compliant
> > > >
> > > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[
> > > CLIC]
> > > >  or both a CLIC and and PLIC.
> > > >
> > > >  If using just a PLIC the system must continue to use the original
> > > > basic @@ -303,38 +324,9 @@ must be supported.
> > > >  Embedded systems cannot use a non-compliant interrupt controller
> > > and
> > > > still
> > > >  call it a PLIC or CLIC.
> > > >
> > > > -==== Machine Timer
> > > > -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> > > > must be -implemented. The two registers must be memory mapped as
> > > > required
> > > by
> > > > the RISC-V
> > > > -specification.
> > > > -
> > > > -The Embedded-2022 specification requires that the registers be
> > > > mapped -adjacent to each other with the `mtime` region at the
> > > > lower
> > > address.
> > > > -
> > > > -The starting address of this region can be located anywhere in
> > > > -memory, including inside other peripherals, as long as the start
> > > > address is
> > > > -4 byte aligned.
> > > > -
> > > > -An example of the memory layout for a 32-bit system with a single
> > > > hart is below
> > > > -
> > > > --------------------------
> > > > -=========================
> > > > -| 0x00 |  mtime low     |
> > > > -| 0x04 |  mtime high    |
> > > > -| 0x08 |  mtimecmp low  |
> > > > -| 0x0C |  mtimecmp high |
> > > > -=========================
> > > > --------------------------
> > > > -
> > > > -and for a 64-bit system with 2 harts
> > > > -
> > > > ----------------------------
> > > > -===========================
> > > > -| 0x00 |  mtime           |
> > > > -| 0x08 |  mtimecmp hart 1 |
> > > > -| 0x10 |  mtimecmp hart 2 |
> > > > -===========================
> > > > ----------------------------
> > > > +==== Machine Mode Timer
> > > > +The Embedded-2022 specification requires RISC-V
> > > > <<MachineModeTimer,Machine mode timer>> to be implemented.
> > > > +The Machine mode timer could be incorporated with the Core Local
> > > > Interrupt (<<CLINT, CLINT>>) or the specific event trigger
> > > mechanism
> > >
> > > CLINT is INTerruptor not just Interrupt.
> > >
> >
> > yes, will correct it
> > >
> > > > according to the platform design.
> > >
> > > What specific trigger mechanism?
> > >
> >
> > platform implementation-specific trigger mechanism?  or just remove
>
> I meant you didn't say what the mechanism is. It should be explicit, so that
> there are no ambiguities.
>
> > this? I put this just because the previous feedback says a small
> > system may not have CLINT for the m-mode timer.
>
> I would be in favour of saying either do what we already have written here OR
> a CLINT.
>
> If we go with something else that's ok, we just need to be clear about what it
> is.
>
> > >
> > > >
> > > >  ==== Memory Map
> > > >  It is recommended that main memory and loadable code (not ROM)
> > > start
> > > > at
> > > > @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> > > > include at least 4 regions, although
> > > >  if possible more should be supported to allow more flexibility.
> > > > Hardware
> > > >  implementations should aim for supporting at least 16 PMP
> > > > regions.
> > > >
> > > > +// Appendix sections
> > > > +== Appendix
> > > > +=== Machine Mode Timer Registers [[MachineModeTimerRegs]] The
> > > > +base address of Machine mode timer operation parameters is
> > > > platform implementation-specific. The Machine mode timer compare
> > > > registers (`mtimecmp`) for each hart is located at offset 0 and
> > > > the layout is organized as below table.
> > >
> > > Can we maintain what we have for the embedded spec?
> > >
> >
> > Do you mean to maintain the register layout(offset) originally defined
> > in the 2.2.3. for embedded systems?
>
> Yes. I worry that mandating a CLINT layout is too restrictive and that no one
> will end up following the embedded-2022 spec then. I would be in favour of
> saying CLINT or the memory layout we already have.

The ACLINT spec does not enforce any memory layout.
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

The ACLINT is backward compatible to CLINT we should refer ACLINT
in-place of CLINT. This gives platform vendors flexibility to choose
their or memory layout and implement only certain parts of ACLINT
as required.

Hi Anup and Alistair. 
With ACLINT spec defined, I think we can revise this patch as below,
1.Remove CLINT from platform spec
2 Mention ACLINT in platform spec for Linux2020 platform and have a link to https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc.
3. Remove Machine mode timer from system peripheral because that is in the scope of ACLINT
4. For Embedded-2022 platform, mention Machine mode timer and refer to ACLINT for the definition of registers.
Any other thoughts?

Abner


Regards,
Anup

>
> > I think we have the register layout as below to be compliant with the
> > m-mode timer registers defined in SiFive CLINT.
>
> I don't think that's flexible enough and that vendors won't want to follow it as
> they already have other IP they are using for timers.
>
> Alistair
>
> > Or do you mean something else?
> >
> > >  It allows the
> > > memory maps to be inside of a MMIO device. For example they can be
> > > registers inside of a general system controller.
> > >
> > >
> > > Also it looks like the lines are a little long here, can be bring
> > > them back to 80 charecters?
> > >
> >
> > sure.
> > >
> > > > +
> > > > +.Registers layout of mtimecmp
> > > > +[width="60%",cols="1,^3,^3"]
> > > > +|=======
> > > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > > RV32*
> > > > +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > > > +|`0x0004` ||mtimecmp high for hart 0
> > > > +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > > > +|`0x000c` ||mtimecmp high for hart 1
> > > > +|... ||
> > > > +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > > > +|`0x7ff4` ||mtimecmp high for hart 4094
> > > > +|=======
> > > > +
> > > > +The Machine mode timer counter (`mtime`) is located at offset
> > > 0x7ff8
> > > > from the base address of operation parameters.
> > > > +
> > > > +.Registers layout of mtime
> > > > +[width="60%",cols="1,^3,^3"]
> > > > +|=======
> > > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > > RV32*
> > > > +|`0x7ff8` |mtime|mtime low
> > > > +|`0x7ffc` ||mtime high
> > > > +|=======
> > >
> > > Are you saying for a small embedded single core CPU we need to put
> > > mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
> > > addresses between them?
> > >
> > > Alistair
> > >
> > > > +
> > > >  // acknowledge all of the contributors
> > > >  include::contributors.adoc[]
> > >
>
>
>
>
>


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Anup Patel
 

Hi Alistar,

-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Alistair Francis
Sent: 24 May 2021 12:54
To: renba.chang@...
Cc: sunilvl@...; tech-unixplatformspec@...;
mchitale@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-
spec: PLIC and CLINT for Linux-2022 platform

On Mon, 2021-05-24 at 14:52 +0800, Abner Chang wrote:


Alistair Francis <Alistair.Francis@...> 於 2021年5月24日 週一
上午11:42寫道:
On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
From: Abner Chang <renba.chang@...>

Initial description of PLIC  CLINT section of Linux-2022 platform.

Is this what we want to see of CLINT/Machine mode timer in the
platform spec?

On v4 commit,
- PLIC section with [DEPRECATED] in Linux- 2022 chapter
- CLINT section in Linux- 2022 chapter for M-mode timer. We don't
mention
  IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not
mandatory.
- Separate section in appendix for the Machine mode timer
registers

On v3 commit,
- Address review comments.

On v2 commit,
- CLINT is not deprecated.

- Add a standalone section for Machine Mode Timer in System
Peripherals.
  Do you think this is a good place for Machine Mode Timer?
  @Mayuresh, please check if you are ok with this change, not sure
if
this
  overlaps with your text or not (The timer setion). I can remove
this
  if you prefer to put this with your patch.

- In Embedded-2022, refer to Machine Mode Timer in System
Peripherals
  section and CLINT in Linux-2022 Platform.
  @Alistair, is this ok?

On v1 commit,
- Not sure where to put the [DEPRECATED].
- Change the reference of PLIC in section 2.2.2. Interrupt
Controller
to
  1.1.3.2 PLIC + CLINT section.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Alistair Francis <alistair.francis@...>
Cc: Sunil V L <sunilvl@...>
Cc: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
--
--
--
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..f8838ab 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,15 +49,37 @@ include::profiles.adoc[]
 * Start Address

 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== AIA[[AIA]]
+===== PLIC[DEPRECATED][[PLIC]]
+The Platform Level Interrupt Controller (PLIC) provides
facilities
to route
+the non-local interrupts to the external interrupt of a hart
context
+with a given privilege mode in a given hart. The number of non-
local
interrupt
+sources supported by PLIC and how does each of them connect to
the
hart
+context is PLIC core implementation-specific. + (Refer to
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc
[RISC-V
 PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== CLINT[[CLINT]]
+On the contrast to PLIC, the Core Local Interrupt (CLINT)
provides
I don't think this is a contrast to the PLIC, it's just a different
functionality.
Can rephase it.

I'm also not sure the CLINT should be in the interrupt controller
section. It is the Core Local INTerruptor (CLINT), not an interrupt
controller.
Hmm.. CLINT is not a sort of interrupt controller but seems to me it
is unnecessary to create another section apart from the Interrupt
Controller section.
It probably makes more sense to add a timer section and put the CLNIT there
instead of forcing it into the interrupt controller section, when it isn't really an
interrupt controller.


+facilities to trigger local interrupt of
<<MachineModeTimer,Machine
mode timer>> to hart.
+
+===== Interrupt Assignments

 ==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+===== UART/Serial Console
+===== Clocks
+===== Timers
+
+===== Machine Mode Timer[[MachineModeTimer]] Machine mode
timer
+is required for Linux-2022 platform and
incorporate with
+<<CLINT,CLINT>> to trigger the timer event to hart. The format
of
Machine mode timer operation parameters
+(`mtime` and `mtimecmp` registers) must compliant with RISC-V
s/must compliant/must be compliant/g
will correct this

Privilege specification section 3.1.10.
+The base address of the memory map registers of Machine mode
timer
is platform implementation-specific,
+however the offset of `mtime` and `mtimecmp` registers are fixed
as
+<<machineModeTimerRegs,Machine mode timer registers>>.
+
+
+===== Watchdog Timers

 ==== Boot Process
 * Firmware
@@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
can
meet the Embedded-2022
 specification.

 ==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant
-https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
-
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[
CLIC]
+Embedded systems are recommended to use a spec compliant
<<PLIC,PLIC>>, a spec
+compliant
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[
CLIC]
 or both a CLIC and and PLIC.

 If using just a PLIC the system must continue to use the original
basic @@ -303,38 +324,9 @@ must be supported.
 Embedded systems cannot use a non-compliant interrupt controller
and
still
 call it a PLIC or CLIC.

-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
must be -implemented. The two registers must be memory mapped as
required
by
the RISC-V
-specification.
-
-The Embedded-2022 specification requires that the registers be
mapped -adjacent to each other with the `mtime` region at the
lower
address.
-
-The starting address of this region can be located anywhere in
-memory, including inside other peripherals, as long as the start
address is
-4 byte aligned.
-
-An example of the memory layout for a 32-bit system with a single
hart is below
-
--------------------------
-=========================
-| 0x00 |  mtime low     |
-| 0x04 |  mtime high    |
-| 0x08 |  mtimecmp low  |
-| 0x0C |  mtimecmp high |
-=========================
--------------------------
-
-and for a 64-bit system with 2 harts
-
----------------------------
-===========================
-| 0x00 |  mtime           |
-| 0x08 |  mtimecmp hart 1 |
-| 0x10 |  mtimecmp hart 2 |
-===========================
----------------------------
+==== Machine Mode Timer
+The Embedded-2022 specification requires RISC-V
<<MachineModeTimer,Machine mode timer>> to be implemented.
+The Machine mode timer could be incorporated with the Core Local
Interrupt (<<CLINT, CLINT>>) or the specific event trigger
mechanism

CLINT is INTerruptor not just Interrupt.
yes, will correct it

according to the platform design.
What specific trigger mechanism?
platform implementation-specific trigger mechanism?  or just remove
I meant you didn't say what the mechanism is. It should be explicit, so that
there are no ambiguities.

this? I put this just because the previous feedback says a small
system may not have CLINT for the m-mode timer.
I would be in favour of saying either do what we already have written here OR
a CLINT.

If we go with something else that's ok, we just need to be clear about what it
is.



 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM)
start
at
@@ -349,5 +341,33 @@ When PMP is supported it is recommended to
include at least 4 regions, although
 if possible more should be supported to allow more flexibility.
Hardware
 implementations should aim for supporting at least 16 PMP
regions.

+// Appendix sections
+== Appendix
+=== Machine Mode Timer Registers [[MachineModeTimerRegs]] The
+base address of Machine mode timer operation parameters is
platform implementation-specific. The Machine mode timer compare
registers (`mtimecmp`) for each hart is located at offset 0 and
the layout is organized as below table.
Can we maintain what we have for the embedded spec?
Do you mean to maintain the register layout(offset) originally defined
in the 2.2.3. for embedded systems?
Yes. I worry that mandating a CLINT layout is too restrictive and that no one
will end up following the embedded-2022 spec then. I would be in favour of
saying CLINT or the memory layout we already have.
The ACLINT spec does not enforce any memory layout.
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

The ACLINT is backward compatible to CLINT we should refer ACLINT
in-place of CLINT. This gives platform vendors flexibility to choose
their or memory layout and implement only certain parts of ACLINT
as required.

Regards,
Anup


I think we have the register layout as below to be compliant with the
m-mode timer registers defined in SiFive CLINT.
I don't think that's flexible enough and that vendors won't want to follow it as
they already have other IP they are using for timers.

Alistair

Or do you mean something else?

 It allows the
memory maps to be inside of a MMIO device. For example they can be
registers inside of a general system controller.


Also it looks like the lines are a little long here, can be bring
them back to 80 charecters?
sure.

+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x0004` ||mtimecmp high for hart 0
+|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x000c` ||mtimecmp high for hart 1
+|... ||
+|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0x7ff4` ||mtimecmp high for hart 4094
+|=======
+
+The Machine mode timer counter (`mtime`) is located at offset
0x7ff8
from the base address of operation parameters.
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x7ff8` |mtime|mtime low
+|`0x7ffc` ||mtime high
+|=======
Are you saying for a small embedded single core CPU we need to put
mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
addresses between them?

Alistair

+
 // acknowledge all of the contributors
 include::contributors.adoc[]




Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Anup Patel
 

Hi Abner,

 

Yesterday, we move ACLINT spec under the RISC-V International GitHub.

 

New link of the ACLINT spec is:

https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

 

You can even clone https://github.com/riscv/riscv-aclint.git and build a PDF version of the ACLINT spec.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 25 May 2021 09:47
To: Alistair Francis <Alistair.Francis@...>
Cc: sunilvl@...; tech-unixplatformspec@...; mchitale@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

 

 

 

Alistair Francis <Alistair.Francis@...> 2021524 週一 下午3:23寫道:

On Mon, 2021-05-24 at 14:52 +0800, Abner Chang wrote:
>
>
> Alistair Francis <Alistair.Francis@...> 2021524 週一
> 上午11:42寫道:
> > On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> > > From: Abner Chang <renba.chang@...>
> > >
> > > Initial description of PLIC  CLINT section of Linux-2022
> > > platform.
> > >
> > > Is this what we want to see of CLINT/Machine mode timer in the
> > > platform spec?
> > >
> > > On v4 commit,
> > > - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> > > - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> > > mention
> > >   IPI because AIA already supported it.
> > > - In Embedded-2022 Machine mode timer section, CLINT is not
> > > mandatory.
> > > - Separate section in appendix for the Machine mode timer
> > > registers
> > >
> > > On v3 commit,
> > > - Address review comments.
> > >
> > > On v2 commit,
> > > - CLINT is not deprecated.
> > >
> > > - Add a standalone section for Machine Mode Timer in System
> > > Peripherals.
> > >   Do you think this is a good place for Machine Mode Timer?
> > >   @Mayuresh, please check if you are ok with this change, not
> > > sure
> > if
> > > this
> > >   overlaps with your text or not (The timer setion). I can remove
> > > this
> > >   if you prefer to put this with your patch.
> > >
> > > - In Embedded-2022, refer to Machine Mode Timer in System
> > Peripherals
> > >   section and CLINT in Linux-2022 Platform.
> > >   @Alistair, is this ok?
> > >
> > > On v1 commit,
> > > - Not sure where to put the [DEPRECATED].
> > > - Change the reference of PLIC in section 2.2.2. Interrupt
> > Controller
> > > to
> > >   1.1.3.2 PLIC + CLINT section.
> > >
> > > Signed-off-by: Abner Chang <renba.chang@...>
> > > Cc: Alistair Francis <alistair.francis@...>
> > > Cc: Sunil V L <sunilvl@...>
> > > Cc: Mayuresh Chitale <mchitale@...>
> > > ---
> > >  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
> > > --
> > --
> > > --
> > >  1 file changed, 62 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > > index 160c74a..f8838ab 100644
> > > --- a/riscv-platform-spec.adoc
> > > +++ b/riscv-platform-spec.adoc
> > > @@ -49,15 +49,37 @@ include::profiles.adoc[]
> > >  * Start Address
> > >  
> > >  ==== Interrupt Controller
> > > -* AIA
> > > -* PLIC + CLINT
> > > -* Interrupt Assignments
> > > +===== AIA[[AIA]]
> > > +===== PLIC[DEPRECATED][[PLIC]]
> > > +The Platform Level Interrupt Controller (PLIC) provides
> > > facilities
> > > to route
> > > +the non-local interrupts to the external interrupt of a hart
> > context
> > > +with a given privilege mode in a given hart. The number of non-
> > local
> > > interrupt
> > > +sources supported by PLIC and how does each of them connect to
> > > the
> > > hart
> > > +context is PLIC core implementation-specific. +
> > > +(Refer to   
> > >
> > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
> > >  PLIC Specification]
> > > +for the implementation reference of PLIC operation parameters)
> > > +
> > > +===== CLINT[[CLINT]]
> > > +On the contrast to PLIC, the Core Local Interrupt (CLINT)
> > > provides
> >
> > I don't think this is a contrast to the PLIC, it's just a different
> > functionality.
> >
>
> Can rephase it. 
> >
> > I'm also not sure the CLINT should be in the interrupt controller
> > section. It is the Core Local INTerruptor (CLINT), not an interrupt
> > controller.
> >
>
> Hmm.. CLINT is not a sort of interrupt controller but seems to me it
> is unnecessary to create another section apart from the Interrupt
> Controller section.

It probably makes more sense to add a timer section and put the CLNIT
there instead of forcing it into the interrupt controller section, when
it isn't really an interrupt controller.

> >
> > > +facilities to trigger local interrupt of
> > <<MachineModeTimer,Machine
> > > mode timer>> to hart.
> > > +
> > > +===== Interrupt Assignments
> > >  
> > >  ==== System Peripherals
> > > -* UART/Serial Console
> > > -* Clocks
> > > -* Timers
> > > -* Watchdog Timers
> > > +===== UART/Serial Console
> > > +===== Clocks
> > > +===== Timers
> > > +
> > > +===== Machine Mode Timer[[MachineModeTimer]]
> > > +Machine mode timer is required for Linux-2022 platform and
> > > incorporate with
> > > +<<CLINT,CLINT>> to trigger the timer event to hart. The format
> > > of
> > > Machine mode timer operation parameters
> > > +(`mtime` and `mtimecmp` registers) must compliant with RISC-V
> >
> > s/must compliant/must be compliant/g
> >
>
> will correct this 
> >
> > > Privilege specification section 3.1.10.
> > > +The base address of the memory map registers of Machine mode
> > > timer
> > > is platform implementation-specific,
> > > +however the offset of `mtime` and `mtimecmp` registers are fixed
> > as
> > > +<<machineModeTimerRegs,Machine mode timer registers>>.
> > > +
> > > +
> > > +===== Watchdog Timers
> > >  
> > >  ==== Boot Process
> > >  * Firmware
> > > @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
> > can
> > > meet the Embedded-2022
> > >  specification.
> > >  
> > >  ==== Interrupt Controller
> > > -Embedded systems are recommended to use a spec compliant
> > > -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> > > -       
> > >
> > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> > > +Embedded systems are recommended to use a spec compliant
> > > <<PLIC,PLIC>>, a spec
> > > +compliant         
> > >
> > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> > >  or both a CLIC and and PLIC.
> > >  
> > >  If using just a PLIC the system must continue to use the
> > > original
> > > basic
> > > @@ -303,38 +324,9 @@ must be supported.
> > >  Embedded systems cannot use a non-compliant interrupt controller
> > and
> > > still
> > >  call it a PLIC or CLIC.
> > >  
> > > -==== Machine Timer
> > > -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> > > must be
> > > -implemented. The two registers must be memory mapped as required
> > by
> > > the RISC-V
> > > -specification.
> > > -
> > > -The Embedded-2022 specification requires that the registers be
> > > mapped
> > > -adjacent to each other with the `mtime` region at the lower
> > address.
> > > -
> > > -The starting address of this region can be located anywhere in
> > > -memory, including inside other peripherals, as long as the start
> > > address is
> > > -4 byte aligned.
> > > -
> > > -An example of the memory layout for a 32-bit system with a
> > > single
> > > hart is below
> > > -
> > > --------------------------
> > > -=========================
> > > -| 0x00 |  mtime low     |
> > > -| 0x04 |  mtime high    |
> > > -| 0x08 |  mtimecmp low  |
> > > -| 0x0C |  mtimecmp high |
> > > -=========================
> > > --------------------------
> > > -
> > > -and for a 64-bit system with 2 harts
> > > -
> > > ----------------------------
> > > -===========================
> > > -| 0x00 |  mtime           |
> > > -| 0x08 |  mtimecmp hart 1 |
> > > -| 0x10 |  mtimecmp hart 2 |
> > > -===========================
> > > ----------------------------
> > > +==== Machine Mode Timer
> > > +The Embedded-2022 specification requires RISC-V
> > > <<MachineModeTimer,Machine mode timer>> to be implemented.
> > > +The Machine mode timer could be incorporated with the Core Local
> > > Interrupt (<<CLINT, CLINT>>) or the specific event trigger
> > mechanism
> >
> > CLINT is INTerruptor not just Interrupt.
> >
>
> yes, will correct it
> >
> > > according to the platform design.
> >
> > What specific trigger mechanism?
> >
>
> platform implementation-specific trigger mechanism?  or just remove

I meant you didn't say what the mechanism is. It should be explicit, so
that there are no ambiguities.

> this? I put this just because the previous feedback says a small
> system may not have CLINT for the m-mode timer.

I would be in favour of saying either do what we already have written
here OR a CLINT.

If we go with something else that's ok, we just need to be clear about
what it is.

> >
> > >  
> > >  ==== Memory Map
> > >  It is recommended that main memory and loadable code (not ROM)
> > start
> > > at
> > > @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> > > include at least 4 regions, although
> > >  if possible more should be supported to allow more flexibility.
> > > Hardware
> > >  implementations should aim for supporting at least 16 PMP
> > > regions.
> > >  
> > > +// Appendix sections
> > > +== Appendix
> > > +=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
> > > +The base address of Machine mode timer operation parameters is
> > > platform implementation-specific. The Machine mode timer compare
> > > registers (`mtimecmp`) for each hart is located at offset 0 and
> > > the
> > > layout is organized as below table.
> >
> > Can we maintain what we have for the embedded spec?
> >
>
> Do you mean to maintain the register layout(offset) originally
> defined in the 2.2.3. for embedded systems? 

Yes. I worry that mandating a CLINT layout is too restrictive and that
no one will end up following the embedded-2022 spec then. I would be in
favour of saying CLINT or the memory layout we already have.

> I think we have the register layout as below to be compliant with the
> m-mode timer registers defined in SiFive CLINT.

I don't think that's flexible enough and that vendors won't want to
follow it as they already have other IP they are using for timers.

Alistair

 

I will remove CLINT from this patch. 

@Anup, how do you define the MTIME registers in ACLINT? Can we just define the base address for both mtimecmp and mtime thus we can have 0 based offset?

 

Abner

 


> Or do you mean something else?
>
> >  It allows the
> > memory maps to be inside of a MMIO device. For example they can be
> > registers inside of a general system controller.
> >
> >
> > Also it looks like the lines are a little long here, can be bring
> > them
> > back to 80 charecters?
> >
>
> sure. 
> >
> > > +
> > > +.Registers layout of mtimecmp
> > > +[width="60%",cols="1,^3,^3"]
> > > +|=======
> > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > > +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > > +|`0x0004` ||mtimecmp high for hart 0
> > > +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > > +|`0x000c` ||mtimecmp high for hart 1
> > > +|... ||
> > > +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > > +|`0x7ff4` ||mtimecmp high for hart 4094
> > > +|=======
> > > +
> > > +The Machine mode timer counter (`mtime`) is located at offset
> > 0x7ff8
> > > from the base address of operation parameters.
> > > +
> > > +.Registers layout of mtime
> > > +[width="60%",cols="1,^3,^3"]
> > > +|=======
> > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > > +|`0x7ff8` |mtime|mtime low
> > > +|`0x7ffc` ||mtime high
> > > +|=======
> >
> > Are you saying for a small embedded single core CPU we need to put
> > mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
> > addresses between them?
> >
> > Alistair
> >
> > > +
> > >  // acknowledge all of the contributors
> > >  include::contributors.adoc[]
> >


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Abner Chang
 



Alistair Francis <Alistair.Francis@...> 於 2021年5月24日 週一 下午3:23寫道:
On Mon, 2021-05-24 at 14:52 +0800, Abner Chang wrote:
>
>
> Alistair Francis <Alistair.Francis@...> 於 2021年5月24日 週一
> 上午11:42寫道:
> > On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> > > From: Abner Chang <renba.chang@...>
> > >
> > > Initial description of PLIC  CLINT section of Linux-2022
> > > platform.
> > >
> > > Is this what we want to see of CLINT/Machine mode timer in the
> > > platform spec?
> > >
> > > On v4 commit,
> > > - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> > > - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> > > mention
> > >   IPI because AIA already supported it.
> > > - In Embedded-2022 Machine mode timer section, CLINT is not
> > > mandatory.
> > > - Separate section in appendix for the Machine mode timer
> > > registers
> > >
> > > On v3 commit,
> > > - Address review comments.
> > >
> > > On v2 commit,
> > > - CLINT is not deprecated.
> > >
> > > - Add a standalone section for Machine Mode Timer in System
> > > Peripherals.
> > >   Do you think this is a good place for Machine Mode Timer?
> > >   @Mayuresh, please check if you are ok with this change, not
> > > sure
> > if
> > > this
> > >   overlaps with your text or not (The timer setion). I can remove
> > > this
> > >   if you prefer to put this with your patch.
> > >
> > > - In Embedded-2022, refer to Machine Mode Timer in System
> > Peripherals
> > >   section and CLINT in Linux-2022 Platform.
> > >   @Alistair, is this ok?
> > >
> > > On v1 commit,
> > > - Not sure where to put the [DEPRECATED].
> > > - Change the reference of PLIC in section 2.2.2. Interrupt
> > Controller
> > > to
> > >   1.1.3.2 PLIC + CLINT section.
> > >
> > > Signed-off-by: Abner Chang <renba.chang@...>
> > > Cc: Alistair Francis <alistair.francis@...>
> > > Cc: Sunil V L <sunilvl@...>
> > > Cc: Mayuresh Chitale <mchitale@...>
> > > ---
> > >  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
> > > --
> > --
> > > --
> > >  1 file changed, 62 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > > index 160c74a..f8838ab 100644
> > > --- a/riscv-platform-spec.adoc
> > > +++ b/riscv-platform-spec.adoc
> > > @@ -49,15 +49,37 @@ include::profiles.adoc[]
> > >  * Start Address
> > >  
> > >  ==== Interrupt Controller
> > > -* AIA
> > > -* PLIC + CLINT
> > > -* Interrupt Assignments
> > > +===== AIA[[AIA]]
> > > +===== PLIC[DEPRECATED][[PLIC]]
> > > +The Platform Level Interrupt Controller (PLIC) provides
> > > facilities
> > > to route
> > > +the non-local interrupts to the external interrupt of a hart
> > context
> > > +with a given privilege mode in a given hart. The number of non-
> > local
> > > interrupt
> > > +sources supported by PLIC and how does each of them connect to
> > > the
> > > hart
> > > +context is PLIC core implementation-specific. +
> > > +(Refer to   
> > >
> > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
> > >  PLIC Specification]
> > > +for the implementation reference of PLIC operation parameters)
> > > +
> > > +===== CLINT[[CLINT]]
> > > +On the contrast to PLIC, the Core Local Interrupt (CLINT)
> > > provides
> >
> > I don't think this is a contrast to the PLIC, it's just a different
> > functionality.
> >
>
> Can rephase it. 
> >
> > I'm also not sure the CLINT should be in the interrupt controller
> > section. It is the Core Local INTerruptor (CLINT), not an interrupt
> > controller.
> >
>
> Hmm.. CLINT is not a sort of interrupt controller but seems to me it
> is unnecessary to create another section apart from the Interrupt
> Controller section.

It probably makes more sense to add a timer section and put the CLNIT
there instead of forcing it into the interrupt controller section, when
it isn't really an interrupt controller.

> >
> > > +facilities to trigger local interrupt of
> > <<MachineModeTimer,Machine
> > > mode timer>> to hart.
> > > +
> > > +===== Interrupt Assignments
> > >  
> > >  ==== System Peripherals
> > > -* UART/Serial Console
> > > -* Clocks
> > > -* Timers
> > > -* Watchdog Timers
> > > +===== UART/Serial Console
> > > +===== Clocks
> > > +===== Timers
> > > +
> > > +===== Machine Mode Timer[[MachineModeTimer]]
> > > +Machine mode timer is required for Linux-2022 platform and
> > > incorporate with
> > > +<<CLINT,CLINT>> to trigger the timer event to hart. The format
> > > of
> > > Machine mode timer operation parameters
> > > +(`mtime` and `mtimecmp` registers) must compliant with RISC-V
> >
> > s/must compliant/must be compliant/g
> >
>
> will correct this 
> >
> > > Privilege specification section 3.1.10.
> > > +The base address of the memory map registers of Machine mode
> > > timer
> > > is platform implementation-specific,
> > > +however the offset of `mtime` and `mtimecmp` registers are fixed
> > as
> > > +<<machineModeTimerRegs,Machine mode timer registers>>.
> > > +
> > > +
> > > +===== Watchdog Timers
> > >  
> > >  ==== Boot Process
> > >  * Firmware
> > > @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
> > can
> > > meet the Embedded-2022
> > >  specification.
> > >  
> > >  ==== Interrupt Controller
> > > -Embedded systems are recommended to use a spec compliant
> > > -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> > > -       
> > >
> > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> > > +Embedded systems are recommended to use a spec compliant
> > > <<PLIC,PLIC>>, a spec
> > > +compliant         
> > >
> > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> > >  or both a CLIC and and PLIC.
> > >  
> > >  If using just a PLIC the system must continue to use the
> > > original
> > > basic
> > > @@ -303,38 +324,9 @@ must be supported.
> > >  Embedded systems cannot use a non-compliant interrupt controller
> > and
> > > still
> > >  call it a PLIC or CLIC.
> > >  
> > > -==== Machine Timer
> > > -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> > > must be
> > > -implemented. The two registers must be memory mapped as required
> > by
> > > the RISC-V
> > > -specification.
> > > -
> > > -The Embedded-2022 specification requires that the registers be
> > > mapped
> > > -adjacent to each other with the `mtime` region at the lower
> > address.
> > > -
> > > -The starting address of this region can be located anywhere in
> > > -memory, including inside other peripherals, as long as the start
> > > address is
> > > -4 byte aligned.
> > > -
> > > -An example of the memory layout for a 32-bit system with a
> > > single
> > > hart is below
> > > -
> > > --------------------------
> > > -=========================
> > > -| 0x00 |  mtime low     |
> > > -| 0x04 |  mtime high    |
> > > -| 0x08 |  mtimecmp low  |
> > > -| 0x0C |  mtimecmp high |
> > > -=========================
> > > --------------------------
> > > -
> > > -and for a 64-bit system with 2 harts
> > > -
> > > ----------------------------
> > > -===========================
> > > -| 0x00 |  mtime           |
> > > -| 0x08 |  mtimecmp hart 1 |
> > > -| 0x10 |  mtimecmp hart 2 |
> > > -===========================
> > > ----------------------------
> > > +==== Machine Mode Timer
> > > +The Embedded-2022 specification requires RISC-V
> > > <<MachineModeTimer,Machine mode timer>> to be implemented.
> > > +The Machine mode timer could be incorporated with the Core Local
> > > Interrupt (<<CLINT, CLINT>>) or the specific event trigger
> > mechanism
> >
> > CLINT is INTerruptor not just Interrupt.
> >
>
> yes, will correct it
> >
> > > according to the platform design.
> >
> > What specific trigger mechanism?
> >
>
> platform implementation-specific trigger mechanism?  or just remove

I meant you didn't say what the mechanism is. It should be explicit, so
that there are no ambiguities.

> this? I put this just because the previous feedback says a small
> system may not have CLINT for the m-mode timer.

I would be in favour of saying either do what we already have written
here OR a CLINT.

If we go with something else that's ok, we just need to be clear about
what it is.

> >
> > >  
> > >  ==== Memory Map
> > >  It is recommended that main memory and loadable code (not ROM)
> > start
> > > at
> > > @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> > > include at least 4 regions, although
> > >  if possible more should be supported to allow more flexibility.
> > > Hardware
> > >  implementations should aim for supporting at least 16 PMP
> > > regions.
> > >  
> > > +// Appendix sections
> > > +== Appendix
> > > +=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
> > > +The base address of Machine mode timer operation parameters is
> > > platform implementation-specific. The Machine mode timer compare
> > > registers (`mtimecmp`) for each hart is located at offset 0 and
> > > the
> > > layout is organized as below table.
> >
> > Can we maintain what we have for the embedded spec?
> >
>
> Do you mean to maintain the register layout(offset) originally
> defined in the 2.2.3. for embedded systems? 

Yes. I worry that mandating a CLINT layout is too restrictive and that
no one will end up following the embedded-2022 spec then. I would be in
favour of saying CLINT or the memory layout we already have.

> I think we have the register layout as below to be compliant with the
> m-mode timer registers defined in SiFive CLINT.

I don't think that's flexible enough and that vendors won't want to
follow it as they already have other IP they are using for timers.

Alistair

I will remove CLINT from this patch. 
@Anup, how do you define the MTIME registers in ACLINT? Can we just define the base address for both mtimecmp and mtime thus we can have 0 based offset?

Abner


> Or do you mean something else?
>
> >  It allows the
> > memory maps to be inside of a MMIO device. For example they can be
> > registers inside of a general system controller.
> >
> >
> > Also it looks like the lines are a little long here, can be bring
> > them
> > back to 80 charecters?
> >
>
> sure. 
> >
> > > +
> > > +.Registers layout of mtimecmp
> > > +[width="60%",cols="1,^3,^3"]
> > > +|=======
> > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > > +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > > +|`0x0004` ||mtimecmp high for hart 0
> > > +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > > +|`0x000c` ||mtimecmp high for hart 1
> > > +|... ||
> > > +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > > +|`0x7ff4` ||mtimecmp high for hart 4094
> > > +|=======
> > > +
> > > +The Machine mode timer counter (`mtime`) is located at offset
> > 0x7ff8
> > > from the base address of operation parameters.
> > > +
> > > +.Registers layout of mtime
> > > +[width="60%",cols="1,^3,^3"]
> > > +|=======
> > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > > +|`0x7ff8` |mtime|mtime low
> > > +|`0x7ffc` ||mtime high
> > > +|=======
> >
> > Are you saying for a small embedded single core CPU we need to put
> > mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
> > addresses between them?
> >
> > Alistair
> >
> > > +
> > >  // acknowledge all of the contributors
> > >  include::contributors.adoc[]
> >


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Abner Chang
 



Anup Patel <Anup.Patel@...> 於 2021年5月24日 週一 下午3:43寫道:


> -----Original Message-----
> From: tech-unixplatformspec@... <tech-
> unixplatformspec@...> On Behalf Of Abner Chang
> Sent: 24 May 2021 08:34
> To: tech-unixplatformspec@...
> Cc: Alistair Francis <Alistair.Francis@...>; Sunil V L
> <sunilvl@...>; Mayuresh Chitale
> <mchitale@...>
> Subject: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-spec:
> PLIC and CLINT for Linux-2022 platform
>
> From: Abner Chang <renba.chang@...>
>
> Initial description of PLIC  CLINT section of Linux-2022 platform.
>
> Is this what we want to see of CLINT/Machine mode timer in the platform
> spec?
>
> On v4 commit,
> - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> - CLINT section in Linux- 2022 chapter for M-mode timer. We don't mention
>   IPI because AIA already supported it.
> - In Embedded-2022 Machine mode timer section, CLINT is not mandatory.
> - Separate section in appendix for the Machine mode timer registers
>
> On v3 commit,
> - Address review comments.
>
> On v2 commit,
> - CLINT is not deprecated.
>
> - Add a standalone section for Machine Mode Timer in System Peripherals.
>   Do you think this is a good place for Machine Mode Timer?
>   @Mayuresh, please check if you are ok with this change, not sure if this
>   overlaps with your text or not (The timer setion). I can remove this
>   if you prefer to put this with your patch.
>
> - In Embedded-2022, refer to Machine Mode Timer in System Peripherals
>   section and CLINT in Linux-2022 Platform.
>   @Alistair, is this ok?
>
> On v1 commit,
> - Not sure where to put the [DEPRECATED].
> - Change the reference of PLIC in section 2.2.2. Interrupt Controller to
>   1.1.3.2 PLIC + CLINT section.
>
> Signed-off-by: Abner Chang <renba.chang@...>
> Cc: Alistair Francis <alistair.francis@...>
> Cc: Sunil V L <sunilvl@...>
> Cc: Mayuresh Chitale <mchitale@...>
> ---
>  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------------
>  1 file changed, 62 insertions(+), 42 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index
> 160c74a..f8838ab 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -49,15 +49,37 @@ include::profiles.adoc[]
>  * Start Address
>
>  ==== Interrupt Controller
> -* AIA
> -* PLIC + CLINT
> -* Interrupt Assignments
> +===== AIA[[AIA]]
> +===== PLIC[DEPRECATED][[PLIC]]
> +The Platform Level Interrupt Controller (PLIC) provides facilities to
> +route the non-local interrupts to the external interrupt of a hart
> +context with a given privilege mode in a given hart. The number of
> +non-local interrupt sources supported by PLIC and how does each of them
> +connect to the hart context is PLIC core implementation-specific. +
> +(Refer to
> +https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RI
> +SC-V PLIC Specification] for the implementation reference of PLIC
> +operation parameters)
> +
> +===== CLINT[[CLINT]]
> +On the contrast to PLIC, the Core Local Interrupt (CLINT) provides
> +facilities to trigger local interrupt of <<MachineModeTimer,Machine mode
> timer>> to hart.

We don't need a CLINT chapter in platform specification anymore.

Instead, we are proposing an Advanced CLINT (or ACLINT) which is:
1) Backward compatible with SiFive CLINT hence existing systems
     will be compliant with new ACLINT spec
2) More modular compared to original CLINT and each functionality
     is defined as a distinct device
3) Provision for S-mode software interrupts
4) Allow multi-socket (or mult-die) systems with multiple MTIMER,
     MSWI, and SSWI devices defined by ACLINT spec.

The ACLINT helps us complete the IPI and Timer story for BASE
and Server platforms. Also, being backward compatible with SiFive
CLINT we don't need to point to define CLINT in platform spec.
This is good, may fix some controversies.

The latest proposal of ACLINT spec is at:
https://github.com/avpatel/riscv-aclint-doc/blob/master/riscv-aclint.adoc
Is this link valid or not public?


The ACLINT proposal was discussed in past platform meeting and
past AIA meeting as well.

Eventually, the ACLINT spec will be owned by RISC-V international
and hosted on RISC-V Github.

@Andrew Waterman can you please review ACLINT proposal ?

Regards,
Anup

> +
> +===== Interrupt Assignments
>
>  ==== System Peripherals
> -* UART/Serial Console
> -* Clocks
> -* Timers
> -* Watchdog Timers
> +===== UART/Serial Console
> +===== Clocks
> +===== Timers
> +
> +===== Machine Mode Timer[[MachineModeTimer]] Machine mode timer is
> +required for Linux-2022 platform and incorporate with <<CLINT,CLINT>>
> +to trigger the timer event to hart. The format of Machine mode timer
> +operation parameters (`mtime` and `mtimecmp` registers) must compliant
> with RISC-V Privilege specification section 3.1.10.
> +The base address of the memory map registers of Machine mode timer is
> +platform implementation-specific, however the offset of `mtime` and
> +`mtimecmp` registers are fixed as <<machineModeTimerRegs,Machine mode
> timer registers>>.
> +
> +
> +===== Watchdog Timers
>
>  ==== Boot Process
>  * Firmware
> @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G can
> meet the Embedded-2022  specification.
>
>  ==== Interrupt Controller
> -Embedded systems are recommended to use a spec compliant -
> https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant -
> https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> +Embedded systems are recommended to use a spec compliant
> <<PLIC,PLIC>>,
> +a spec compliant
> +https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLI
> +C]
>  or both a CLIC and and PLIC.
>
>  If using just a PLIC the system must continue to use the original basic @@ -
> 303,38 +324,9 @@ must be supported.
>  Embedded systems cannot use a non-compliant interrupt controller and still
> call it a PLIC or CLIC.
>
> -==== Machine Timer
> -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`) must be -
> implemented. The two registers must be memory mapped as required by the
> RISC-V -specification.
> -
> -The Embedded-2022 specification requires that the registers be mapped -
> adjacent to each other with the `mtime` region at the lower address.
> -
> -The starting address of this region can be located anywhere in -memory,
> including inside other peripherals, as long as the start address is
> -4 byte aligned.
> -
> -An example of the memory layout for a 32-bit system with a single hart is
> below
> -
> --------------------------
> -=========================
> -| 0x00 |  mtime low     |
> -| 0x04 |  mtime high    |
> -| 0x08 |  mtimecmp low  |
> -| 0x0C |  mtimecmp high |
> -=========================
> --------------------------
> -
> -and for a 64-bit system with 2 harts
> -
> ----------------------------
> -===========================
> -| 0x00 |  mtime           |
> -| 0x08 |  mtimecmp hart 1 |
> -| 0x10 |  mtimecmp hart 2 |
> -===========================
> ----------------------------
> +==== Machine Mode Timer
> +The Embedded-2022 specification requires RISC-V
> <<MachineModeTimer,Machine mode timer>> to be implemented.
> +The Machine mode timer could be incorporated with the Core Local
> Interrupt (<<CLINT, CLINT>>) or the specific event trigger mechanism
> according to the platform design.
>
>  ==== Memory Map
>  It is recommended that main memory and loadable code (not ROM) start at
> @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> include at least 4 regions, although  if possible more should be supported to
> allow more flexibility. Hardware  implementations should aim for supporting
> at least 16 PMP regions.
>
> +// Appendix sections
> +== Appendix
> +=== Machine Mode Timer Registers [[MachineModeTimerRegs]] The base
> +address of Machine mode timer operation parameters is platform
> implementation-specific. The Machine mode timer compare registers
> (`mtimecmp`) for each hart is located at offset 0 and the layout is organized
> as below table.
> +
> +.Registers layout of mtimecmp
> +[width="60%",cols="1,^3,^3"]
> +|=======
> +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
> +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0 `0x0004`
> +|||mtimecmp high for hart 0 `0x0008` |mtimecmp for hart 1 |mtimecmp
> low
> +|for hart 1 `0x000c` ||mtimecmp high for hart 1 ... || `0x7ff0`
> +||mtimecmp for hart 4094|mtimecmp low for hart 4094 `0x7ff4`
> ||mtimecmp
> +|high for hart 4094 =======
> +
> +The Machine mode timer counter (`mtime`) is located at offset 0x7ff8 from
> the base address of operation parameters.
> +
> +.Registers layout of mtime
> +[width="60%",cols="1,^3,^3"]
> +|=======
> +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
> +|`0x7ff8` |mtime|mtime low `0x7ffc` ||mtime high =======
> +
>  // acknowledge all of the contributors
>  include::contributors.adoc[]
> --
> 2.19.0.windows.1
>
>
>
>
>


Re: [PATCH v5 0/2] System Peripherals

Mayuresh Chitale
 

Thanks Jonathan.


On Sat, May 22, 2021 at 11:16 PM Jonathan Behrens <behrensj@...> wrote:
This all looks good to me now.

Reviewed-by: Jonathan Behrens <behrensj@...>


On Fri, May 21, 2021 at 4:41 AM Mayuresh Chitale via lists.riscv.org <mchitale=ventanamicro.com@...> wrote:
This patch describes requirements for the system peripherals
like UART, clock and timers for the Linux-2022 platform
base spec and the server extension.

Changes in V5:
  - Rebased on main

Changes in V4:
  - Rephrased the requirement for minimum counter resolution

Changes in V3:

Base spec:
  - Clarified minimum requirement for counter resolution.

Server extension:
  - Removed watchdog timers section which to be moved into a separate patch.

Changes in V2:

Rephrased the requirements to use 'required' keyword instead of 'shall'.

Base spec:
  UART:
    - Added 8250 as deprecated and 16550 as mandatory

  Clock and Timers:
    - Move time csr, sstc requirement to server extension

Server extension:
  - Added Clock and Timers requirements
  - Added implementation notes for clock and watchdog timers

Changes in V1:
 - Initial draft for base spec only.

Mayuresh Chitale (2):
  Updating contributors
  System Peripherals: Linux 2022 Base spec and server extension

 contributors.adoc        |  3 ++-
 riscv-platform-spec.adoc | 43 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 42 insertions(+), 4 deletions(-)

--
2.17.1







Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Anup Patel
 

-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Abner Chang
Sent: 24 May 2021 08:34
To: tech-unixplatformspec@...
Cc: Alistair Francis <Alistair.Francis@...>; Sunil V L
<sunilvl@...>; Mayuresh Chitale
<mchitale@...>
Subject: [RISC-V] [tech-unixplatformspec] [PATCH v4 1/2] riscv-platform-spec:
PLIC and CLINT for Linux-2022 platform

From: Abner Chang <renba.chang@...>

Initial description of PLIC CLINT section of Linux-2022 platform.

Is this what we want to see of CLINT/Machine mode timer in the platform
spec?

On v4 commit,
- PLIC section with [DEPRECATED] in Linux- 2022 chapter
- CLINT section in Linux- 2022 chapter for M-mode timer. We don't mention
IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not mandatory.
- Separate section in appendix for the Machine mode timer registers

On v3 commit,
- Address review comments.

On v2 commit,
- CLINT is not deprecated.

- Add a standalone section for Machine Mode Timer in System Peripherals.
Do you think this is a good place for Machine Mode Timer?
@Mayuresh, please check if you are ok with this change, not sure if this
overlaps with your text or not (The timer setion). I can remove this
if you prefer to put this with your patch.

- In Embedded-2022, refer to Machine Mode Timer in System Peripherals
section and CLINT in Linux-2022 Platform.
@Alistair, is this ok?

On v1 commit,
- Not sure where to put the [DEPRECATED].
- Change the reference of PLIC in section 2.2.2. Interrupt Controller to
1.1.3.2 PLIC + CLINT section.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Alistair Francis <alistair.francis@...>
Cc: Sunil V L <sunilvl@...>
Cc: Mayuresh Chitale <mchitale@...>
---
riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------------
1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index
160c74a..f8838ab 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,15 +49,37 @@ include::profiles.adoc[]
* Start Address

==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== AIA[[AIA]]
+===== PLIC[DEPRECATED][[PLIC]]
+The Platform Level Interrupt Controller (PLIC) provides facilities to
+route the non-local interrupts to the external interrupt of a hart
+context with a given privilege mode in a given hart. The number of
+non-local interrupt sources supported by PLIC and how does each of them
+connect to the hart context is PLIC core implementation-specific. +
+(Refer to
+https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RI
+SC-V PLIC Specification] for the implementation reference of PLIC
+operation parameters)
+
+===== CLINT[[CLINT]]
+On the contrast to PLIC, the Core Local Interrupt (CLINT) provides
+facilities to trigger local interrupt of <<MachineModeTimer,Machine mode
timer>> to hart.
We don't need a CLINT chapter in platform specification anymore.

Instead, we are proposing an Advanced CLINT (or ACLINT) which is:
1) Backward compatible with SiFive CLINT hence existing systems
will be compliant with new ACLINT spec
2) More modular compared to original CLINT and each functionality
is defined as a distinct device
3) Provision for S-mode software interrupts
4) Allow multi-socket (or mult-die) systems with multiple MTIMER,
MSWI, and SSWI devices defined by ACLINT spec.

The ACLINT helps us complete the IPI and Timer story for BASE
and Server platforms. Also, being backward compatible with SiFive
CLINT we don't need to point to define CLINT in platform spec.

The latest proposal of ACLINT spec is at:
https://github.com/avpatel/riscv-aclint-doc/blob/master/riscv-aclint.adoc

The ACLINT proposal was discussed in past platform meeting and
past AIA meeting as well.

Eventually, the ACLINT spec will be owned by RISC-V international
and hosted on RISC-V Github.

@Andrew Waterman can you please review ACLINT proposal ?

Regards,
Anup

+
+===== Interrupt Assignments

==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+===== UART/Serial Console
+===== Clocks
+===== Timers
+
+===== Machine Mode Timer[[MachineModeTimer]] Machine mode timer is
+required for Linux-2022 platform and incorporate with <<CLINT,CLINT>>
+to trigger the timer event to hart. The format of Machine mode timer
+operation parameters (`mtime` and `mtimecmp` registers) must compliant
with RISC-V Privilege specification section 3.1.10.
+The base address of the memory map registers of Machine mode timer is
+platform implementation-specific, however the offset of `mtime` and
+`mtimecmp` registers are fixed as <<machineModeTimerRegs,Machine mode
timer registers>>.
+
+
+===== Watchdog Timers

==== Boot Process
* Firmware
@@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G can
meet the Embedded-2022 specification.

==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant -
https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant -
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+Embedded systems are recommended to use a spec compliant
<<PLIC,PLIC>>,
+a spec compliant
+https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLI
+C]
or both a CLIC and and PLIC.

If using just a PLIC the system must continue to use the original basic @@ -
303,38 +324,9 @@ must be supported.
Embedded systems cannot use a non-compliant interrupt controller and still
call it a PLIC or CLIC.

-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`) must be -
implemented. The two registers must be memory mapped as required by the
RISC-V -specification.
-
-The Embedded-2022 specification requires that the registers be mapped -
adjacent to each other with the `mtime` region at the lower address.
-
-The starting address of this region can be located anywhere in -memory,
including inside other peripherals, as long as the start address is
-4 byte aligned.
-
-An example of the memory layout for a 32-bit system with a single hart is
below
-
--------------------------
-=========================
-| 0x00 | mtime low |
-| 0x04 | mtime high |
-| 0x08 | mtimecmp low |
-| 0x0C | mtimecmp high |
-=========================
--------------------------
-
-and for a 64-bit system with 2 harts
-
----------------------------
-===========================
-| 0x00 | mtime |
-| 0x08 | mtimecmp hart 1 |
-| 0x10 | mtimecmp hart 2 |
-===========================
----------------------------
+==== Machine Mode Timer
+The Embedded-2022 specification requires RISC-V
<<MachineModeTimer,Machine mode timer>> to be implemented.
+The Machine mode timer could be incorporated with the Core Local
Interrupt (<<CLINT, CLINT>>) or the specific event trigger mechanism
according to the platform design.

==== Memory Map
It is recommended that main memory and loadable code (not ROM) start at
@@ -349,5 +341,33 @@ When PMP is supported it is recommended to
include at least 4 regions, although if possible more should be supported to
allow more flexibility. Hardware implementations should aim for supporting
at least 16 PMP regions.

+// Appendix sections
+== Appendix
+=== Machine Mode Timer Registers [[MachineModeTimerRegs]] The base
+address of Machine mode timer operation parameters is platform
implementation-specific. The Machine mode timer compare registers
(`mtimecmp`) for each hart is located at offset 0 and the layout is organized
as below table.
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0 `0x0004`
+|||mtimecmp high for hart 0 `0x0008` |mtimecmp for hart 1 |mtimecmp
low
+|for hart 1 `0x000c` ||mtimecmp high for hart 1 ... || `0x7ff0`
+||mtimecmp for hart 4094|mtimecmp low for hart 4094 `0x7ff4`
||mtimecmp
+|high for hart 4094 =======
+
+The Machine mode timer counter (`mtime`) is located at offset 0x7ff8 from
the base address of operation parameters.
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x7ff8` |mtime|mtime low `0x7ffc` ||mtime high =======
+
// acknowledge all of the contributors
include::contributors.adoc[]
--
2.19.0.windows.1





Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Alistair Francis
 

On Mon, 2021-05-24 at 14:52 +0800, Abner Chang wrote:


Alistair Francis <Alistair.Francis@...> 於 2021年5月24日 週一
上午11:42寫道:
On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
From: Abner Chang <renba.chang@...>

Initial description of PLIC  CLINT section of Linux-2022
platform.

Is this what we want to see of CLINT/Machine mode timer in the
platform spec?

On v4 commit,
- PLIC section with [DEPRECATED] in Linux- 2022 chapter
- CLINT section in Linux- 2022 chapter for M-mode timer. We don't
mention
  IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not
mandatory.
- Separate section in appendix for the Machine mode timer
registers

On v3 commit,
- Address review comments.

On v2 commit,
- CLINT is not deprecated.

- Add a standalone section for Machine Mode Timer in System
Peripherals.
  Do you think this is a good place for Machine Mode Timer?
  @Mayuresh, please check if you are ok with this change, not
sure
if
this
  overlaps with your text or not (The timer setion). I can remove
this
  if you prefer to put this with your patch.

- In Embedded-2022, refer to Machine Mode Timer in System
Peripherals
  section and CLINT in Linux-2022 Platform.
  @Alistair, is this ok?

On v1 commit,
- Not sure where to put the [DEPRECATED].
- Change the reference of PLIC in section 2.2.2. Interrupt
Controller
to
  1.1.3.2 PLIC + CLINT section.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Alistair Francis <alistair.francis@...>
Cc: Sunil V L <sunilvl@...>
Cc: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
--
--
--
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..f8838ab 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,15 +49,37 @@ include::profiles.adoc[]
 * Start Address
 
 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== AIA[[AIA]]
+===== PLIC[DEPRECATED][[PLIC]]
+The Platform Level Interrupt Controller (PLIC) provides
facilities
to route
+the non-local interrupts to the external interrupt of a hart
context
+with a given privilege mode in a given hart. The number of non-
local
interrupt
+sources supported by PLIC and how does each of them connect to
the
hart
+context is PLIC core implementation-specific. +
+(Refer to   
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
 PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== CLINT[[CLINT]]
+On the contrast to PLIC, the Core Local Interrupt (CLINT)
provides
I don't think this is a contrast to the PLIC, it's just a different
functionality.
Can rephase it. 

I'm also not sure the CLINT should be in the interrupt controller
section. It is the Core Local INTerruptor (CLINT), not an interrupt
controller.
Hmm.. CLINT is not a sort of interrupt controller but seems to me it
is unnecessary to create another section apart from the Interrupt
Controller section.
It probably makes more sense to add a timer section and put the CLNIT
there instead of forcing it into the interrupt controller section, when
it isn't really an interrupt controller.


+facilities to trigger local interrupt of
<<MachineModeTimer,Machine
mode timer>> to hart.
+
+===== Interrupt Assignments
 
 ==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+===== UART/Serial Console
+===== Clocks
+===== Timers
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and
incorporate with
+<<CLINT,CLINT>> to trigger the timer event to hart. The format
of
Machine mode timer operation parameters
+(`mtime` and `mtimecmp` registers) must compliant with RISC-V
s/must compliant/must be compliant/g
will correct this 

Privilege specification section 3.1.10.
+The base address of the memory map registers of Machine mode
timer
is platform implementation-specific,
+however the offset of `mtime` and `mtimecmp` registers are fixed
as
+<<machineModeTimerRegs,Machine mode timer registers>>.
+
+
+===== Watchdog Timers
 
 ==== Boot Process
 * Firmware
@@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
can
meet the Embedded-2022
 specification.
 
 ==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant
-https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
-       
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+Embedded systems are recommended to use a spec compliant
<<PLIC,PLIC>>, a spec
+compliant         
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
 or both a CLIC and and PLIC.
 
 If using just a PLIC the system must continue to use the
original
basic
@@ -303,38 +324,9 @@ must be supported.
 Embedded systems cannot use a non-compliant interrupt controller
and
still
 call it a PLIC or CLIC.
 
-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
must be
-implemented. The two registers must be memory mapped as required
by
the RISC-V
-specification.
-
-The Embedded-2022 specification requires that the registers be
mapped
-adjacent to each other with the `mtime` region at the lower
address.
-
-The starting address of this region can be located anywhere in
-memory, including inside other peripherals, as long as the start
address is
-4 byte aligned.
-
-An example of the memory layout for a 32-bit system with a
single
hart is below
-
--------------------------
-=========================
-| 0x00 |  mtime low     |
-| 0x04 |  mtime high    |
-| 0x08 |  mtimecmp low  |
-| 0x0C |  mtimecmp high |
-=========================
--------------------------
-
-and for a 64-bit system with 2 harts
-
----------------------------
-===========================
-| 0x00 |  mtime           |
-| 0x08 |  mtimecmp hart 1 |
-| 0x10 |  mtimecmp hart 2 |
-===========================
----------------------------
+==== Machine Mode Timer
+The Embedded-2022 specification requires RISC-V
<<MachineModeTimer,Machine mode timer>> to be implemented.
+The Machine mode timer could be incorporated with the Core Local
Interrupt (<<CLINT, CLINT>>) or the specific event trigger
mechanism

CLINT is INTerruptor not just Interrupt.
yes, will correct it

according to the platform design.
What specific trigger mechanism?
platform implementation-specific trigger mechanism?  or just remove
I meant you didn't say what the mechanism is. It should be explicit, so
that there are no ambiguities.

this? I put this just because the previous feedback says a small
system may not have CLINT for the m-mode timer.
I would be in favour of saying either do what we already have written
here OR a CLINT.

If we go with something else that's ok, we just need to be clear about
what it is.


 
 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM)
start
at
@@ -349,5 +341,33 @@ When PMP is supported it is recommended to
include at least 4 regions, although
 if possible more should be supported to allow more flexibility.
Hardware
 implementations should aim for supporting at least 16 PMP
regions.
 
+// Appendix sections
+== Appendix
+=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
+The base address of Machine mode timer operation parameters is
platform implementation-specific. The Machine mode timer compare
registers (`mtimecmp`) for each hart is located at offset 0 and
the
layout is organized as below table.
Can we maintain what we have for the embedded spec?
Do you mean to maintain the register layout(offset) originally
defined in the 2.2.3. for embedded systems? 
Yes. I worry that mandating a CLINT layout is too restrictive and that
no one will end up following the embedded-2022 spec then. I would be in
favour of saying CLINT or the memory layout we already have.

I think we have the register layout as below to be compliant with the
m-mode timer registers defined in SiFive CLINT.
I don't think that's flexible enough and that vendors won't want to
follow it as they already have other IP they are using for timers.

Alistair

Or do you mean something else?

 It allows the
memory maps to be inside of a MMIO device. For example they can be
registers inside of a general system controller.


Also it looks like the lines are a little long here, can be bring
them
back to 80 charecters?
sure. 

+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x0004` ||mtimecmp high for hart 0
+|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x000c` ||mtimecmp high for hart 1
+|... ||
+|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0x7ff4` ||mtimecmp high for hart 4094
+|=======
+
+The Machine mode timer counter (`mtime`) is located at offset
0x7ff8
from the base address of operation parameters.
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x7ff8` |mtime|mtime low
+|`0x7ffc` ||mtime high
+|=======
Are you saying for a small embedded single core CPU we need to put
mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
addresses between them?

Alistair

+
 // acknowledge all of the contributors
 include::contributors.adoc[]


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Abner Chang
 



Alistair Francis <Alistair.Francis@...> 於 2021年5月24日 週一 上午11:42寫道:
On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> From: Abner Chang <renba.chang@...>
>
> Initial description of PLIC  CLINT section of Linux-2022 platform.
>
> Is this what we want to see of CLINT/Machine mode timer in the
> platform spec?
>
> On v4 commit,
> - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> mention
>   IPI because AIA already supported it.
> - In Embedded-2022 Machine mode timer section, CLINT is not
> mandatory.
> - Separate section in appendix for the Machine mode timer registers
>
> On v3 commit,
> - Address review comments.
>
> On v2 commit,
> - CLINT is not deprecated.
>
> - Add a standalone section for Machine Mode Timer in System
> Peripherals.
>   Do you think this is a good place for Machine Mode Timer?
>   @Mayuresh, please check if you are ok with this change, not sure if
> this
>   overlaps with your text or not (The timer setion). I can remove
> this
>   if you prefer to put this with your patch.
>
> - In Embedded-2022, refer to Machine Mode Timer in System Peripherals
>   section and CLINT in Linux-2022 Platform.
>   @Alistair, is this ok?
>
> On v1 commit,
> - Not sure where to put the [DEPRECATED].
> - Change the reference of PLIC in section 2.2.2. Interrupt Controller
> to
>   1.1.3.2 PLIC + CLINT section.
>
> Signed-off-by: Abner Chang <renba.chang@...>
> Cc: Alistair Francis <alistair.francis@...>
> Cc: Sunil V L <sunilvl@...>
> Cc: Mayuresh Chitale <mchitale@...>
> ---
>  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++--------------
> --
>  1 file changed, 62 insertions(+), 42 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 160c74a..f8838ab 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -49,15 +49,37 @@ include::profiles.adoc[]
>  * Start Address
>  
>  ==== Interrupt Controller
> -* AIA
> -* PLIC + CLINT
> -* Interrupt Assignments
> +===== AIA[[AIA]]
> +===== PLIC[DEPRECATED][[PLIC]]
> +The Platform Level Interrupt Controller (PLIC) provides facilities
> to route
> +the non-local interrupts to the external interrupt of a hart context
> +with a given privilege mode in a given hart. The number of non-local
> interrupt
> +sources supported by PLIC and how does each of them connect to the
> hart
> +context is PLIC core implementation-specific. +
> +(Refer to   
> https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
>  PLIC Specification]
> +for the implementation reference of PLIC operation parameters)
> +
> +===== CLINT[[CLINT]]
> +On the contrast to PLIC, the Core Local Interrupt (CLINT) provides

I don't think this is a contrast to the PLIC, it's just a different
functionality.
Can rephase it. 

I'm also not sure the CLINT should be in the interrupt controller
section. It is the Core Local INTerruptor (CLINT), not an interrupt
controller.
Hmm.. CLINT is not a sort of interrupt controller but seems to me it is unnecessary to create another section apart from the Interrupt Controller section.

> +facilities to trigger local interrupt of <<MachineModeTimer,Machine
> mode timer>> to hart.
> +
> +===== Interrupt Assignments
>  
>  ==== System Peripherals
> -* UART/Serial Console
> -* Clocks
> -* Timers
> -* Watchdog Timers
> +===== UART/Serial Console
> +===== Clocks
> +===== Timers
> +
> +===== Machine Mode Timer[[MachineModeTimer]]
> +Machine mode timer is required for Linux-2022 platform and
> incorporate with
> +<<CLINT,CLINT>> to trigger the timer event to hart. The format of
> Machine mode timer operation parameters
> +(`mtime` and `mtimecmp` registers) must compliant with RISC-V

s/must compliant/must be compliant/g
will correct this 

> Privilege specification section 3.1.10.
> +The base address of the memory map registers of Machine mode timer
> is platform implementation-specific,
> +however the offset of `mtime` and `mtimecmp` registers are fixed as
> +<<machineModeTimerRegs,Machine mode timer registers>>.
> +
> +
> +===== Watchdog Timers
>  
>  ==== Boot Process
>  * Firmware
> @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G can
> meet the Embedded-2022
>  specification.
>  
>  ==== Interrupt Controller
> -Embedded systems are recommended to use a spec compliant
> -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> -       
> https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> +Embedded systems are recommended to use a spec compliant
> <<PLIC,PLIC>>, a spec
> +compliant         
> https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
>  or both a CLIC and and PLIC.
>  
>  If using just a PLIC the system must continue to use the original
> basic
> @@ -303,38 +324,9 @@ must be supported.
>  Embedded systems cannot use a non-compliant interrupt controller and
> still
>  call it a PLIC or CLIC.
>  
> -==== Machine Timer
> -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> must be
> -implemented. The two registers must be memory mapped as required by
> the RISC-V
> -specification.
> -
> -The Embedded-2022 specification requires that the registers be
> mapped
> -adjacent to each other with the `mtime` region at the lower address.
> -
> -The starting address of this region can be located anywhere in
> -memory, including inside other peripherals, as long as the start
> address is
> -4 byte aligned.
> -
> -An example of the memory layout for a 32-bit system with a single
> hart is below
> -
> --------------------------
> -=========================
> -| 0x00 |  mtime low     |
> -| 0x04 |  mtime high    |
> -| 0x08 |  mtimecmp low  |
> -| 0x0C |  mtimecmp high |
> -=========================
> --------------------------
> -
> -and for a 64-bit system with 2 harts
> -
> ----------------------------
> -===========================
> -| 0x00 |  mtime           |
> -| 0x08 |  mtimecmp hart 1 |
> -| 0x10 |  mtimecmp hart 2 |
> -===========================
> ----------------------------
> +==== Machine Mode Timer
> +The Embedded-2022 specification requires RISC-V
> <<MachineModeTimer,Machine mode timer>> to be implemented.
> +The Machine mode timer could be incorporated with the Core Local
> Interrupt (<<CLINT, CLINT>>) or the specific event trigger mechanism

CLINT is INTerruptor not just Interrupt.
yes, will correct it

> according to the platform design.

What specific trigger mechanism?
platform implementation-specific trigger mechanism?  or just remove this? I put this just because the previous feedback says a small system may not have CLINT for the m-mode timer.

>  
>  ==== Memory Map
>  It is recommended that main memory and loadable code (not ROM) start
> at
> @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> include at least 4 regions, although
>  if possible more should be supported to allow more flexibility.
> Hardware
>  implementations should aim for supporting at least 16 PMP regions.
>  
> +// Appendix sections
> +== Appendix
> +=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
> +The base address of Machine mode timer operation parameters is
> platform implementation-specific. The Machine mode timer compare
> registers (`mtimecmp`) for each hart is located at offset 0 and the
> layout is organized as below table.

Can we maintain what we have for the embedded spec?
Do you mean to maintain the register layout(offset) originally defined in the 2.2.3. for embedded systems? 
I think we have the register layout as below to be compliant with the m-mode timer registers defined in SiFive CLINT.
Or do you mean something else?

It allows the
memory maps to be inside of a MMIO device. For example they can be
registers inside of a general system controller.

Also it looks like the lines are a little long here, can be bring them
back to 80 charecters?
sure. 

> +
> +.Registers layout of mtimecmp
> +[width="60%",cols="1,^3,^3"]
> +|=======
> +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
> +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> +|`0x0004` ||mtimecmp high for hart 0
> +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> +|`0x000c` ||mtimecmp high for hart 1
> +|... ||
> +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> +|`0x7ff4` ||mtimecmp high for hart 4094
> +|=======
> +
> +The Machine mode timer counter (`mtime`) is located at offset 0x7ff8
> from the base address of operation parameters.
> +
> +.Registers layout of mtime
> +[width="60%",cols="1,^3,^3"]
> +|=======
> +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
> +|`0x7ff8` |mtime|mtime low
> +|`0x7ffc` ||mtime high
> +|=======

Are you saying for a small embedded single core CPU we need to put
mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
addresses between them?

Alistair

> +
>  // acknowledge all of the contributors
>  include::contributors.adoc[]


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Andrew Waterman
 



On Sun, May 23, 2021 at 9:33 PM Alistair Francis <Alistair.Francis@...> wrote:
On Sun, 2021-05-23 at 20:49 -0700, Andrew Waterman wrote:
>
>
> On Sun, May 23, 2021 at 8:42 PM Alistair Francis < 
> alistair.francis@...> wrote:
> > On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> > > From: Abner Chang <renba.chang@...>
> > >
> > > Initial description of PLIC  CLINT section of Linux-2022
> > > platform.
> > >
> > > Is this what we want to see of CLINT/Machine mode timer in the
> > > platform spec?
> > >
> > > On v4 commit,
> > > - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> > > - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> > > mention
> > >   IPI because AIA already supported it.
> > > - In Embedded-2022 Machine mode timer section, CLINT is not
> > > mandatory.
> > > - Separate section in appendix for the Machine mode timer
> > > registers
> > >
> > > On v3 commit,
> > > - Address review comments.
> > >
> > > On v2 commit,
> > > - CLINT is not deprecated.
> > >
> > > - Add a standalone section for Machine Mode Timer in System
> > > Peripherals.
> > >   Do you think this is a good place for Machine Mode Timer?
> > >   @Mayuresh, please check if you are ok with this change, not
> > > sure
> > if
> > > this
> > >   overlaps with your text or not (The timer setion). I can remove
> > > this
> > >   if you prefer to put this with your patch.
> > >
> > > - In Embedded-2022, refer to Machine Mode Timer in System
> > Peripherals
> > >   section and CLINT in Linux-2022 Platform.
> > >   @Alistair, is this ok?
> > >
> > > On v1 commit,
> > > - Not sure where to put the [DEPRECATED].
> > > - Change the reference of PLIC in section 2.2.2. Interrupt
> > Controller
> > > to
> > >   1.1.3.2 PLIC + CLINT section.
> > >
> > > Signed-off-by: Abner Chang <renba.chang@...>
> > > Cc: Alistair Francis <alistair.francis@...>
> > > Cc: Sunil V L <sunilvl@...>
> > > Cc: Mayuresh Chitale <mchitale@...>
> > > ---
> > >  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
> > > --
> > --
> > > --
> > >  1 file changed, 62 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > > index 160c74a..f8838ab 100644
> > > --- a/riscv-platform-spec.adoc
> > > +++ b/riscv-platform-spec.adoc
> > > @@ -49,15 +49,37 @@ include::profiles.adoc[]
> > >  * Start Address
> > >  
> > >  ==== Interrupt Controller
> > > -* AIA
> > > -* PLIC + CLINT
> > > -* Interrupt Assignments
> > > +===== AIA[[AIA]]
> > > +===== PLIC[DEPRECATED][[PLIC]]
> > > +The Platform Level Interrupt Controller (PLIC) provides
> > > facilities
> > > to route
> > > +the non-local interrupts to the external interrupt of a hart
> > context
> > > +with a given privilege mode in a given hart. The number of non-
> > local
> > > interrupt
> > > +sources supported by PLIC and how does each of them connect to
> > > the
> > > hart
> > > +context is PLIC core implementation-specific. +
> > > +(Refer to   
> > >
> > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
> > >  PLIC Specification]
> > > +for the implementation reference of PLIC operation parameters)
> > > +
> > > +===== CLINT[[CLINT]]
> > > +On the contrast to PLIC, the Core Local Interrupt (CLINT)
> > > provides
> >
> > I don't think this is a contrast to the PLIC, it's just a different
> > functionality.
> >
> > I'm also not sure the CLINT should be in the interrupt controller
> > section. It is the Core Local INTerruptor (CLINT), not an interrupt
> > controller.
> >
> > > +facilities to trigger local interrupt of
> > <<MachineModeTimer,Machine
> > > mode timer>> to hart.
> > > +
> > > +===== Interrupt Assignments
> > >  
> > >  ==== System Peripherals
> > > -* UART/Serial Console
> > > -* Clocks
> > > -* Timers
> > > -* Watchdog Timers
> > > +===== UART/Serial Console
> > > +===== Clocks
> > > +===== Timers
> > > +
> > > +===== Machine Mode Timer[[MachineModeTimer]]
> > > +Machine mode timer is required for Linux-2022 platform and
> > > incorporate with
> > > +<<CLINT,CLINT>> to trigger the timer event to hart. The format
> > > of
> > > Machine mode timer operation parameters
> > > +(`mtime` and `mtimecmp` registers) must compliant with RISC-V
> >
> > s/must compliant/must be compliant/g
> >
> > > Privilege specification section 3.1.10.
> > > +The base address of the memory map registers of Machine mode
> > > timer
> > > is platform implementation-specific,
> > > +however the offset of `mtime` and `mtimecmp` registers are fixed
> > as
> > > +<<machineModeTimerRegs,Machine mode timer registers>>.
> > > +
> > > +
> > > +===== Watchdog Timers
> > >  
> > >  ==== Boot Process
> > >  * Firmware
> > > @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
> > can
> > > meet the Embedded-2022
> > >  specification.
> > >  
> > >  ==== Interrupt Controller
> > > -Embedded systems are recommended to use a spec compliant
> > > -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> > > -       
> > >
> > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> > > +Embedded systems are recommended to use a spec compliant
> > > <<PLIC,PLIC>>, a spec
> > > +compliant         
> > >
> > https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> > >  or both a CLIC and and PLIC.
> > >  
> > >  If using just a PLIC the system must continue to use the
> > > original
> > > basic
> > > @@ -303,38 +324,9 @@ must be supported.
> > >  Embedded systems cannot use a non-compliant interrupt controller
> > and
> > > still
> > >  call it a PLIC or CLIC.
> > >  
> > > -==== Machine Timer
> > > -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> > > must be
> > > -implemented. The two registers must be memory mapped as required
> > by
> > > the RISC-V
> > > -specification.
> > > -
> > > -The Embedded-2022 specification requires that the registers be
> > > mapped
> > > -adjacent to each other with the `mtime` region at the lower
> > address.
> > > -
> > > -The starting address of this region can be located anywhere in
> > > -memory, including inside other peripherals, as long as the start
> > > address is
> > > -4 byte aligned.
> > > -
> > > -An example of the memory layout for a 32-bit system with a
> > > single
> > > hart is below
> > > -
> > > --------------------------
> > > -=========================
> > > -| 0x00 |  mtime low     |
> > > -| 0x04 |  mtime high    |
> > > -| 0x08 |  mtimecmp low  |
> > > -| 0x0C |  mtimecmp high |
> > > -=========================
> > > --------------------------
> > > -
> > > -and for a 64-bit system with 2 harts
> > > -
> > > ----------------------------
> > > -===========================
> > > -| 0x00 |  mtime           |
> > > -| 0x08 |  mtimecmp hart 1 |
> > > -| 0x10 |  mtimecmp hart 2 |
> > > -===========================
> > > ----------------------------
> > > +==== Machine Mode Timer
> > > +The Embedded-2022 specification requires RISC-V
> > > <<MachineModeTimer,Machine mode timer>> to be implemented.
> > > +The Machine mode timer could be incorporated with the Core Local
> > > Interrupt (<<CLINT, CLINT>>) or the specific event trigger
> > mechanism
> >
> > CLINT is INTerruptor not just Interrupt.
> >
> > > according to the platform design.
> >
> > What specific trigger mechanism?
> >
> > >  
> > >  ==== Memory Map
> > >  It is recommended that main memory and loadable code (not ROM)
> > start
> > > at
> > > @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> > > include at least 4 regions, although
> > >  if possible more should be supported to allow more flexibility.
> > > Hardware
> > >  implementations should aim for supporting at least 16 PMP
> > > regions.
> > >  
> > > +// Appendix sections
> > > +== Appendix
> > > +=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
> > > +The base address of Machine mode timer operation parameters is
> > > platform implementation-specific. The Machine mode timer compare
> > > registers (`mtimecmp`) for each hart is located at offset 0 and
> > > the
> > > layout is organized as below table.
> >
> > Can we maintain what we have for the embedded spec? It allows the
> > memory maps to be inside of a MMIO device. For example they can be
> > registers inside of a general system controller.
> >
> > Also it looks like the lines are a little long here, can be bring
> > them
> > back to 80 charecters?
> >
> > > +
> > > +.Registers layout of mtimecmp
> > > +[width="60%",cols="1,^3,^3"]
> > > +|=======
> > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > > +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > > +|`0x0004` ||mtimecmp high for hart 0
> > > +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > > +|`0x000c` ||mtimecmp high for hart 1
> > > +|... ||
> > > +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > > +|`0x7ff4` ||mtimecmp high for hart 4094
> > > +|=======
> > > +
> > > +The Machine mode timer counter (`mtime`) is located at offset
> > 0x7ff8
> > > from the base address of operation parameters.
> > > +
> > > +.Registers layout of mtime
> > > +[width="60%",cols="1,^3,^3"]
> > > +|=======
> > > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > > +|`0x7ff8` |mtime|mtime low
> > > +|`0x7ffc` ||mtime high
> > > +|=======
> >
> > Are you saying for a small embedded single core CPU we need to put
> > mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
> > addresses between them?
> >
>
>
> What you're hinting at is a false economy.  There really isn't any
> cost to having an empty two pages of address space, even in small,
> embedded single-core systems.

I agree, but if this is included inside a system controller (as mtime
and mtimecmp sometimes are) I'm worried that HW vendors will then just
put them next to each other to condense the address space and not meet
this spec. 

I have seen hardware vendors complain about changing address space
layouts in the past and I'm worried this large gap will be a reason not
to meet the spec. Considering there is already "RISC-V" hardware that
doesn't include mtime/mtimecmp I would like to make this spec as easy
as possible for vendors to meet, so that hopefully everyone does.

In saying that you know a lot more about HW design then me, so if you
think it won't be an issue then we can leave it as is.

People indeed do questionable things all the time.  But I can assure you, this one isn't going to materially affect HW cost, one way or the other.


Alistair

>
> >
> > Alistair
> >
> > > +
> > >  // acknowledge all of the contributors
> > >  include::contributors.adoc[]
> >
> >
> >
> >
> >
> >


Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Alistair Francis
 

On Sun, 2021-05-23 at 20:49 -0700, Andrew Waterman wrote:


On Sun, May 23, 2021 at 8:42 PM Alistair Francis <
alistair.francis@...> wrote:
On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
From: Abner Chang <renba.chang@...>

Initial description of PLIC  CLINT section of Linux-2022
platform.

Is this what we want to see of CLINT/Machine mode timer in the
platform spec?

On v4 commit,
- PLIC section with [DEPRECATED] in Linux- 2022 chapter
- CLINT section in Linux- 2022 chapter for M-mode timer. We don't
mention
  IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not
mandatory.
- Separate section in appendix for the Machine mode timer
registers

On v3 commit,
- Address review comments.

On v2 commit,
- CLINT is not deprecated.

- Add a standalone section for Machine Mode Timer in System
Peripherals.
  Do you think this is a good place for Machine Mode Timer?
  @Mayuresh, please check if you are ok with this change, not
sure
if
this
  overlaps with your text or not (The timer setion). I can remove
this
  if you prefer to put this with your patch.

- In Embedded-2022, refer to Machine Mode Timer in System
Peripherals
  section and CLINT in Linux-2022 Platform.
  @Alistair, is this ok?

On v1 commit,
- Not sure where to put the [DEPRECATED].
- Change the reference of PLIC in section 2.2.2. Interrupt
Controller
to
  1.1.3.2 PLIC + CLINT section.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Alistair Francis <alistair.francis@...>
Cc: Sunil V L <sunilvl@...>
Cc: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------
--
--
--
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..f8838ab 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,15 +49,37 @@ include::profiles.adoc[]
 * Start Address
 
 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== AIA[[AIA]]
+===== PLIC[DEPRECATED][[PLIC]]
+The Platform Level Interrupt Controller (PLIC) provides
facilities
to route
+the non-local interrupts to the external interrupt of a hart
context
+with a given privilege mode in a given hart. The number of non-
local
interrupt
+sources supported by PLIC and how does each of them connect to
the
hart
+context is PLIC core implementation-specific. +
+(Refer to   
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
 PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== CLINT[[CLINT]]
+On the contrast to PLIC, the Core Local Interrupt (CLINT)
provides
I don't think this is a contrast to the PLIC, it's just a different
functionality.

I'm also not sure the CLINT should be in the interrupt controller
section. It is the Core Local INTerruptor (CLINT), not an interrupt
controller.

+facilities to trigger local interrupt of
<<MachineModeTimer,Machine
mode timer>> to hart.
+
+===== Interrupt Assignments
 
 ==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+===== UART/Serial Console
+===== Clocks
+===== Timers
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and
incorporate with
+<<CLINT,CLINT>> to trigger the timer event to hart. The format
of
Machine mode timer operation parameters
+(`mtime` and `mtimecmp` registers) must compliant with RISC-V
s/must compliant/must be compliant/g

Privilege specification section 3.1.10.
+The base address of the memory map registers of Machine mode
timer
is platform implementation-specific,
+however the offset of `mtime` and `mtimecmp` registers are fixed
as
+<<machineModeTimerRegs,Machine mode timer registers>>.
+
+
+===== Watchdog Timers
 
 ==== Boot Process
 * Firmware
@@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G
can
meet the Embedded-2022
 specification.
 
 ==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant
-https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
-       
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+Embedded systems are recommended to use a spec compliant
<<PLIC,PLIC>>, a spec
+compliant         
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
 or both a CLIC and and PLIC.
 
 If using just a PLIC the system must continue to use the
original
basic
@@ -303,38 +324,9 @@ must be supported.
 Embedded systems cannot use a non-compliant interrupt controller
and
still
 call it a PLIC or CLIC.
 
-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
must be
-implemented. The two registers must be memory mapped as required
by
the RISC-V
-specification.
-
-The Embedded-2022 specification requires that the registers be
mapped
-adjacent to each other with the `mtime` region at the lower
address.
-
-The starting address of this region can be located anywhere in
-memory, including inside other peripherals, as long as the start
address is
-4 byte aligned.
-
-An example of the memory layout for a 32-bit system with a
single
hart is below
-
--------------------------
-=========================
-| 0x00 |  mtime low     |
-| 0x04 |  mtime high    |
-| 0x08 |  mtimecmp low  |
-| 0x0C |  mtimecmp high |
-=========================
--------------------------
-
-and for a 64-bit system with 2 harts
-
----------------------------
-===========================
-| 0x00 |  mtime           |
-| 0x08 |  mtimecmp hart 1 |
-| 0x10 |  mtimecmp hart 2 |
-===========================
----------------------------
+==== Machine Mode Timer
+The Embedded-2022 specification requires RISC-V
<<MachineModeTimer,Machine mode timer>> to be implemented.
+The Machine mode timer could be incorporated with the Core Local
Interrupt (<<CLINT, CLINT>>) or the specific event trigger
mechanism

CLINT is INTerruptor not just Interrupt.

according to the platform design.
What specific trigger mechanism?

 
 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM)
start
at
@@ -349,5 +341,33 @@ When PMP is supported it is recommended to
include at least 4 regions, although
 if possible more should be supported to allow more flexibility.
Hardware
 implementations should aim for supporting at least 16 PMP
regions.
 
+// Appendix sections
+== Appendix
+=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
+The base address of Machine mode timer operation parameters is
platform implementation-specific. The Machine mode timer compare
registers (`mtimecmp`) for each hart is located at offset 0 and
the
layout is organized as below table.
Can we maintain what we have for the embedded spec? It allows the
memory maps to be inside of a MMIO device. For example they can be
registers inside of a general system controller.

Also it looks like the lines are a little long here, can be bring
them
back to 80 charecters?

+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x0004` ||mtimecmp high for hart 0
+|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x000c` ||mtimecmp high for hart 1
+|... ||
+|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0x7ff4` ||mtimecmp high for hart 4094
+|=======
+
+The Machine mode timer counter (`mtime`) is located at offset
0x7ff8
from the base address of operation parameters.
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x7ff8` |mtime|mtime low
+|`0x7ffc` ||mtime high
+|=======
Are you saying for a small embedded single core CPU we need to put
mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
addresses between them?

What you're hinting at is a false economy.  There really isn't any
cost to having an empty two pages of address space, even in small,
embedded single-core systems.
I agree, but if this is included inside a system controller (as mtime
and mtimecmp sometimes are) I'm worried that HW vendors will then just
put them next to each other to condense the address space and not meet
this spec.

I have seen hardware vendors complain about changing address space
layouts in the past and I'm worried this large gap will be a reason not
to meet the spec. Considering there is already "RISC-V" hardware that
doesn't include mtime/mtimecmp I would like to make this spec as easy
as possible for vendors to meet, so that hopefully everyone does.

In saying that you know a lot more about HW design then me, so if you
think it won't be an issue then we can leave it as is.

Alistair



Alistair

+
 // acknowledge all of the contributors
 include::contributors.adoc[]





Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Andrew Waterman
 



On Sun, May 23, 2021 at 8:42 PM Alistair Francis <alistair.francis@...> wrote:
On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
> From: Abner Chang <renba.chang@...>
>
> Initial description of PLIC  CLINT section of Linux-2022 platform.
>
> Is this what we want to see of CLINT/Machine mode timer in the
> platform spec?
>
> On v4 commit,
> - PLIC section with [DEPRECATED] in Linux- 2022 chapter
> - CLINT section in Linux- 2022 chapter for M-mode timer. We don't
> mention
>   IPI because AIA already supported it.
> - In Embedded-2022 Machine mode timer section, CLINT is not
> mandatory.
> - Separate section in appendix for the Machine mode timer registers
>
> On v3 commit,
> - Address review comments.
>
> On v2 commit,
> - CLINT is not deprecated.
>
> - Add a standalone section for Machine Mode Timer in System
> Peripherals.
>   Do you think this is a good place for Machine Mode Timer?
>   @Mayuresh, please check if you are ok with this change, not sure if
> this
>   overlaps with your text or not (The timer setion). I can remove
> this
>   if you prefer to put this with your patch.
>
> - In Embedded-2022, refer to Machine Mode Timer in System Peripherals
>   section and CLINT in Linux-2022 Platform.
>   @Alistair, is this ok?
>
> On v1 commit,
> - Not sure where to put the [DEPRECATED].
> - Change the reference of PLIC in section 2.2.2. Interrupt Controller
> to
>   1.1.3.2 PLIC + CLINT section.
>
> Signed-off-by: Abner Chang <renba.chang@...>
> Cc: Alistair Francis <alistair.francis@...>
> Cc: Sunil V L <sunilvl@...>
> Cc: Mayuresh Chitale <mchitale@...>
> ---
>  riscv-platform-spec.adoc | 104 +++++++++++++++++++++++--------------
> --
>  1 file changed, 62 insertions(+), 42 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 160c74a..f8838ab 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -49,15 +49,37 @@ include::profiles.adoc[]
>  * Start Address
>  
>  ==== Interrupt Controller
> -* AIA
> -* PLIC + CLINT
> -* Interrupt Assignments
> +===== AIA[[AIA]]
> +===== PLIC[DEPRECATED][[PLIC]]
> +The Platform Level Interrupt Controller (PLIC) provides facilities
> to route
> +the non-local interrupts to the external interrupt of a hart context
> +with a given privilege mode in a given hart. The number of non-local
> interrupt
> +sources supported by PLIC and how does each of them connect to the
> hart
> +context is PLIC core implementation-specific. +
> +(Refer to   
> https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
>  PLIC Specification]
> +for the implementation reference of PLIC operation parameters)
> +
> +===== CLINT[[CLINT]]
> +On the contrast to PLIC, the Core Local Interrupt (CLINT) provides

I don't think this is a contrast to the PLIC, it's just a different
functionality.

I'm also not sure the CLINT should be in the interrupt controller
section. It is the Core Local INTerruptor (CLINT), not an interrupt
controller.

> +facilities to trigger local interrupt of <<MachineModeTimer,Machine
> mode timer>> to hart.
> +
> +===== Interrupt Assignments
>  
>  ==== System Peripherals
> -* UART/Serial Console
> -* Clocks
> -* Timers
> -* Watchdog Timers
> +===== UART/Serial Console
> +===== Clocks
> +===== Timers
> +
> +===== Machine Mode Timer[[MachineModeTimer]]
> +Machine mode timer is required for Linux-2022 platform and
> incorporate with
> +<<CLINT,CLINT>> to trigger the timer event to hart. The format of
> Machine mode timer operation parameters
> +(`mtime` and `mtimecmp` registers) must compliant with RISC-V

s/must compliant/must be compliant/g

> Privilege specification section 3.1.10.
> +The base address of the memory map registers of Machine mode timer
> is platform implementation-specific,
> +however the offset of `mtime` and `mtimecmp` registers are fixed as
> +<<machineModeTimerRegs,Machine mode timer registers>>.
> +
> +
> +===== Watchdog Timers
>  
>  ==== Boot Process
>  * Firmware
> @@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G can
> meet the Embedded-2022
>  specification.
>  
>  ==== Interrupt Controller
> -Embedded systems are recommended to use a spec compliant
> -https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
> -       
> https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
> +Embedded systems are recommended to use a spec compliant
> <<PLIC,PLIC>>, a spec
> +compliant         
> https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
>  or both a CLIC and and PLIC.
>  
>  If using just a PLIC the system must continue to use the original
> basic
> @@ -303,38 +324,9 @@ must be supported.
>  Embedded systems cannot use a non-compliant interrupt controller and
> still
>  call it a PLIC or CLIC.
>  
> -==== Machine Timer
> -The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
> must be
> -implemented. The two registers must be memory mapped as required by
> the RISC-V
> -specification.
> -
> -The Embedded-2022 specification requires that the registers be
> mapped
> -adjacent to each other with the `mtime` region at the lower address.
> -
> -The starting address of this region can be located anywhere in
> -memory, including inside other peripherals, as long as the start
> address is
> -4 byte aligned.
> -
> -An example of the memory layout for a 32-bit system with a single
> hart is below
> -
> --------------------------
> -=========================
> -| 0x00 |  mtime low     |
> -| 0x04 |  mtime high    |
> -| 0x08 |  mtimecmp low  |
> -| 0x0C |  mtimecmp high |
> -=========================
> --------------------------
> -
> -and for a 64-bit system with 2 harts
> -
> ----------------------------
> -===========================
> -| 0x00 |  mtime           |
> -| 0x08 |  mtimecmp hart 1 |
> -| 0x10 |  mtimecmp hart 2 |
> -===========================
> ----------------------------
> +==== Machine Mode Timer
> +The Embedded-2022 specification requires RISC-V
> <<MachineModeTimer,Machine mode timer>> to be implemented.
> +The Machine mode timer could be incorporated with the Core Local
> Interrupt (<<CLINT, CLINT>>) or the specific event trigger mechanism

CLINT is INTerruptor not just Interrupt.

> according to the platform design.

What specific trigger mechanism?

>  
>  ==== Memory Map
>  It is recommended that main memory and loadable code (not ROM) start
> at
> @@ -349,5 +341,33 @@ When PMP is supported it is recommended to
> include at least 4 regions, although
>  if possible more should be supported to allow more flexibility.
> Hardware
>  implementations should aim for supporting at least 16 PMP regions.
>  
> +// Appendix sections
> +== Appendix
> +=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
> +The base address of Machine mode timer operation parameters is
> platform implementation-specific. The Machine mode timer compare
> registers (`mtimecmp`) for each hart is located at offset 0 and the
> layout is organized as below table.

Can we maintain what we have for the embedded spec? It allows the
memory maps to be inside of a MMIO device. For example they can be
registers inside of a general system controller.

Also it looks like the lines are a little long here, can be bring them
back to 80 charecters?

> +
> +.Registers layout of mtimecmp
> +[width="60%",cols="1,^3,^3"]
> +|=======
> +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
> +|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> +|`0x0004` ||mtimecmp high for hart 0
> +|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> +|`0x000c` ||mtimecmp high for hart 1
> +|... ||
> +|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> +|`0x7ff4` ||mtimecmp high for hart 4094
> +|=======
> +
> +The Machine mode timer counter (`mtime`) is located at offset 0x7ff8
> from the base address of operation parameters.
> +
> +.Registers layout of mtime
> +[width="60%",cols="1,^3,^3"]
> +|=======
> +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
> +|`0x7ff8` |mtime|mtime low
> +|`0x7ffc` ||mtime high
> +|=======

Are you saying for a small embedded single core CPU we need to put
mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
addresses between them?

What you're hinting at is a false economy.  There really isn't any cost to having an empty two pages of address space, even in small, embedded single-core systems.


Alistair

> +
>  // acknowledge all of the contributors
>  include::contributors.adoc[]







Re: [PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Alistair Francis
 

On Mon, 2021-05-24 at 11:03 +0800, Abner Chang wrote:
From: Abner Chang <renba.chang@...>

Initial description of PLIC  CLINT section of Linux-2022 platform.

Is this what we want to see of CLINT/Machine mode timer in the
platform spec?

On v4 commit,
- PLIC section with [DEPRECATED] in Linux- 2022 chapter
- CLINT section in Linux- 2022 chapter for M-mode timer. We don't
mention
  IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not
mandatory.
- Separate section in appendix for the Machine mode timer registers

On v3 commit,
- Address review comments.

On v2 commit,
- CLINT is not deprecated.

- Add a standalone section for Machine Mode Timer in System
Peripherals.
  Do you think this is a good place for Machine Mode Timer?
  @Mayuresh, please check if you are ok with this change, not sure if
this
  overlaps with your text or not (The timer setion). I can remove
this
  if you prefer to put this with your patch.

- In Embedded-2022, refer to Machine Mode Timer in System Peripherals
  section and CLINT in Linux-2022 Platform.
  @Alistair, is this ok?

On v1 commit,
- Not sure where to put the [DEPRECATED].
- Change the reference of PLIC in section 2.2.2. Interrupt Controller
to
  1.1.3.2 PLIC + CLINT section.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Alistair Francis <alistair.francis@...>
Cc: Sunil V L <sunilvl@...>
Cc: Mayuresh Chitale <mchitale@...>
---
 riscv-platform-spec.adoc | 104 +++++++++++++++++++++++--------------
--
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..f8838ab 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,15 +49,37 @@ include::profiles.adoc[]
 * Start Address
 
 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== AIA[[AIA]]
+===== PLIC[DEPRECATED][[PLIC]]
+The Platform Level Interrupt Controller (PLIC) provides facilities
to route
+the non-local interrupts to the external interrupt of a hart context
+with a given privilege mode in a given hart. The number of non-local
interrupt
+sources supported by PLIC and how does each of them connect to the
hart
+context is PLIC core implementation-specific. +
+(Refer to
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V
 PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== CLINT[[CLINT]]
+On the contrast to PLIC, the Core Local Interrupt (CLINT) provides
I don't think this is a contrast to the PLIC, it's just a different
functionality.

I'm also not sure the CLINT should be in the interrupt controller
section. It is the Core Local INTerruptor (CLINT), not an interrupt
controller.

+facilities to trigger local interrupt of <<MachineModeTimer,Machine
mode timer>> to hart.
+
+===== Interrupt Assignments
 
 ==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+===== UART/Serial Console
+===== Clocks
+===== Timers
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and
incorporate with
+<<CLINT,CLINT>> to trigger the timer event to hart. The format of
Machine mode timer operation parameters
+(`mtime` and `mtimecmp` registers) must compliant with RISC-V
s/must compliant/must be compliant/g

Privilege specification section 3.1.10.
+The base address of the memory map registers of Machine mode timer
is platform implementation-specific,
+however the offset of `mtime` and `mtimecmp` registers are fixed as
+<<machineModeTimerRegs,Machine mode timer registers>>.
+
+
+===== Watchdog Timers
 
 ==== Boot Process
 * Firmware
@@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G can
meet the Embedded-2022
 specification.
 
 ==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant
-https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
-
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+Embedded systems are recommended to use a spec compliant
<<PLIC,PLIC>>, a spec
+compliant
https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
 or both a CLIC and and PLIC.
 
 If using just a PLIC the system must continue to use the original
basic
@@ -303,38 +324,9 @@ must be supported.
 Embedded systems cannot use a non-compliant interrupt controller and
still
 call it a PLIC or CLIC.
 
-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
must be
-implemented. The two registers must be memory mapped as required by
the RISC-V
-specification.
-
-The Embedded-2022 specification requires that the registers be
mapped
-adjacent to each other with the `mtime` region at the lower address.
-
-The starting address of this region can be located anywhere in
-memory, including inside other peripherals, as long as the start
address is
-4 byte aligned.
-
-An example of the memory layout for a 32-bit system with a single
hart is below
-
--------------------------
-=========================
-| 0x00 |  mtime low     |
-| 0x04 |  mtime high    |
-| 0x08 |  mtimecmp low  |
-| 0x0C |  mtimecmp high |
-=========================
--------------------------
-
-and for a 64-bit system with 2 harts
-
----------------------------
-===========================
-| 0x00 |  mtime           |
-| 0x08 |  mtimecmp hart 1 |
-| 0x10 |  mtimecmp hart 2 |
-===========================
----------------------------
+==== Machine Mode Timer
+The Embedded-2022 specification requires RISC-V
<<MachineModeTimer,Machine mode timer>> to be implemented.
+The Machine mode timer could be incorporated with the Core Local
Interrupt (<<CLINT, CLINT>>) or the specific event trigger mechanism
CLINT is INTerruptor not just Interrupt.

according to the platform design.
What specific trigger mechanism?

 
 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM) start
at
@@ -349,5 +341,33 @@ When PMP is supported it is recommended to
include at least 4 regions, although
 if possible more should be supported to allow more flexibility.
Hardware
 implementations should aim for supporting at least 16 PMP regions.
 
+// Appendix sections
+== Appendix
+=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
+The base address of Machine mode timer operation parameters is
platform implementation-specific. The Machine mode timer compare
registers (`mtimecmp`) for each hart is located at offset 0 and the
layout is organized as below table.
Can we maintain what we have for the embedded spec? It allows the
memory maps to be inside of a MMIO device. For example they can be
registers inside of a general system controller.

Also it looks like the lines are a little long here, can be bring them
back to 80 charecters?

+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x0004` ||mtimecmp high for hart 0
+|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x000c` ||mtimecmp high for hart 1
+|... ||
+|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0x7ff4` ||mtimecmp high for hart 4094
+|=======
+
+The Machine mode timer counter (`mtime`) is located at offset 0x7ff8
from the base address of operation parameters.
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x7ff8` |mtime|mtime low
+|`0x7ffc` ||mtime high
+|=======
Are you saying for a small embedded single core CPU we need to put
mtimecmp at offset 0x00 and mtime at 0x7ff8? What about all the
addresses between them?

Alistair

+
 // acknowledge all of the contributors
 include::contributors.adoc[]


[PATCH v4 2/2] contributors: Add Abner as contributor

Abner Chang
 

From: Abner Chang <renba.chang@...>

Signed-off-by: Abner Chang <renba.chang@...>
---
contributors.adoc | 1 +
1 file changed, 1 insertion(+)

diff --git a/contributors.adoc b/contributors.adoc
index 3d19411..73b99c4 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -27,6 +27,7 @@ Andrew Waterman,
Kumar Sankaran,
Alistair Francis,
Sunil V L.
+Abner Chang

If you have contributed and are not listed, do let us know. We haven't
forgotten you, but we may have forgotten to edit this list.
--
2.19.0.windows.1


[PATCH v4 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Abner Chang
 

From: Abner Chang <renba.chang@...>

Initial description of PLIC CLINT section of Linux-2022 platform.

Is this what we want to see of CLINT/Machine mode timer in the
platform spec?

On v4 commit,
- PLIC section with [DEPRECATED] in Linux- 2022 chapter
- CLINT section in Linux- 2022 chapter for M-mode timer. We don't mention
IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not mandatory.
- Separate section in appendix for the Machine mode timer registers

On v3 commit,
- Address review comments.

On v2 commit,
- CLINT is not deprecated.

- Add a standalone section for Machine Mode Timer in System Peripherals.
Do you think this is a good place for Machine Mode Timer?
@Mayuresh, please check if you are ok with this change, not sure if this
overlaps with your text or not (The timer setion). I can remove this
if you prefer to put this with your patch.

- In Embedded-2022, refer to Machine Mode Timer in System Peripherals
section and CLINT in Linux-2022 Platform.
@Alistair, is this ok?

On v1 commit,
- Not sure where to put the [DEPRECATED].
- Change the reference of PLIC in section 2.2.2. Interrupt Controller to
1.1.3.2 PLIC + CLINT section.

Signed-off-by: Abner Chang <renba.chang@...>
Cc: Alistair Francis <alistair.francis@...>
Cc: Sunil V L <sunilvl@...>
Cc: Mayuresh Chitale <mchitale@...>
---
riscv-platform-spec.adoc | 104 +++++++++++++++++++++++----------------
1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..f8838ab 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,15 +49,37 @@ include::profiles.adoc[]
* Start Address

==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== AIA[[AIA]]
+===== PLIC[DEPRECATED][[PLIC]]
+The Platform Level Interrupt Controller (PLIC) provides facilities to route
+the non-local interrupts to the external interrupt of a hart context
+with a given privilege mode in a given hart. The number of non-local interrupt
+sources supported by PLIC and how does each of them connect to the hart
+context is PLIC core implementation-specific. +
+(Refer to https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc[RISC-V PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== CLINT[[CLINT]]
+On the contrast to PLIC, the Core Local Interrupt (CLINT) provides
+facilities to trigger local interrupt of <<MachineModeTimer,Machine mode timer>> to hart.
+
+===== Interrupt Assignments

==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+===== UART/Serial Console
+===== Clocks
+===== Timers
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and incorporate with
+<<CLINT,CLINT>> to trigger the timer event to hart. The format of Machine mode timer operation parameters
+(`mtime` and `mtimecmp` registers) must compliant with RISC-V Privilege specification section 3.1.10.
+The base address of the memory map registers of Machine mode timer is platform implementation-specific,
+however the offset of `mtime` and `mtimecmp` registers are fixed as
+<<machineModeTimerRegs,Machine mode timer registers>>.
+
+
+===== Watchdog Timers

==== Boot Process
* Firmware
@@ -289,9 +311,8 @@ Any RISC-V system that uses at least RV32/64G can meet the Embedded-2022
specification.

==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant
-https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
-https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
+Embedded systems are recommended to use a spec compliant <<PLIC,PLIC>>, a spec
+compliant https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc[CLIC]
or both a CLIC and and PLIC.

If using just a PLIC the system must continue to use the original basic
@@ -303,38 +324,9 @@ must be supported.
Embedded systems cannot use a non-compliant interrupt controller and still
call it a PLIC or CLIC.

-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`) must be
-implemented. The two registers must be memory mapped as required by the RISC-V
-specification.
-
-The Embedded-2022 specification requires that the registers be mapped
-adjacent to each other with the `mtime` region at the lower address.
-
-The starting address of this region can be located anywhere in
-memory, including inside other peripherals, as long as the start address is
-4 byte aligned.
-
-An example of the memory layout for a 32-bit system with a single hart is below
-
--------------------------
-=========================
-| 0x00 | mtime low |
-| 0x04 | mtime high |
-| 0x08 | mtimecmp low |
-| 0x0C | mtimecmp high |
-=========================
--------------------------
-
-and for a 64-bit system with 2 harts
-
----------------------------
-===========================
-| 0x00 | mtime |
-| 0x08 | mtimecmp hart 1 |
-| 0x10 | mtimecmp hart 2 |
-===========================
----------------------------
+==== Machine Mode Timer
+The Embedded-2022 specification requires RISC-V <<MachineModeTimer,Machine mode timer>> to be implemented.
+The Machine mode timer could be incorporated with the Core Local Interrupt (<<CLINT, CLINT>>) or the specific event trigger mechanism according to the platform design.

==== Memory Map
It is recommended that main memory and loadable code (not ROM) start at
@@ -349,5 +341,33 @@ When PMP is supported it is recommended to include at least 4 regions, although
if possible more should be supported to allow more flexibility. Hardware
implementations should aim for supporting at least 16 PMP regions.

+// Appendix sections
+== Appendix
+=== Machine Mode Timer Registers [[MachineModeTimerRegs]]
+The base address of Machine mode timer operation parameters is platform implementation-specific. The Machine mode timer compare registers (`mtimecmp`) for each hart is located at offset 0 and the layout is organized as below table.
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x0000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x0004` ||mtimecmp high for hart 0
+|`0x0008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x000c` ||mtimecmp high for hart 1
+|... ||
+|`0x7ff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0x7ff4` ||mtimecmp high for hart 4094
+|=======
+
+The Machine mode timer counter (`mtime`) is located at offset 0x7ff8 from the base address of operation parameters.
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x7ff8` |mtime|mtime low
+|`0x7ffc` ||mtime high
+|=======
+
// acknowledge all of the contributors
include::contributors.adoc[]
--
2.19.0.windows.1


Re: [PATCH v5 0/2] System Peripherals

Jonathan Behrens <behrensj@...>
 

This all looks good to me now.

Reviewed-by: Jonathan Behrens <behrensj@...>


On Fri, May 21, 2021 at 4:41 AM Mayuresh Chitale via lists.riscv.org <mchitale=ventanamicro.com@...> wrote:
This patch describes requirements for the system peripherals
like UART, clock and timers for the Linux-2022 platform
base spec and the server extension.

Changes in V5:
  - Rebased on main

Changes in V4:
  - Rephrased the requirement for minimum counter resolution

Changes in V3:

Base spec:
  - Clarified minimum requirement for counter resolution.

Server extension:
  - Removed watchdog timers section which to be moved into a separate patch.

Changes in V2:

Rephrased the requirements to use 'required' keyword instead of 'shall'.

Base spec:
  UART:
    - Added 8250 as deprecated and 16550 as mandatory

  Clock and Timers:
    - Move time csr, sstc requirement to server extension

Server extension:
  - Added Clock and Timers requirements
  - Added implementation notes for clock and watchdog timers

Changes in V1:
 - Initial draft for base spec only.

Mayuresh Chitale (2):
  Updating contributors
  System Peripherals: Linux 2022 Base spec and server extension

 contributors.adoc        |  3 ++-
 riscv-platform-spec.adoc | 43 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 42 insertions(+), 4 deletions(-)

--
2.17.1







[PATCH v7] Add performance monitoring unit extension

Anup Patel
 

This patch adds SBI performance monitoring unit (PMU) extension which
allows S-mode (or VS-mode) software to configure hardware (or firmware)
performance counters with help of M-mode (or HS-mode) software.

Signed-off-by: Anup Patel <anup.patel@...>
Signed-off-by: Atish Patra <atish.patra@...>
---
Changes since v6:
- Additional NOTEs for SBI_PMU_CFG_FLAG_SKIP_MATCH,
SBI_PMU_CFG_FLAG_AUTO_START, and SBI_PMU_START_SET_INIT_VALUE flags
Changes since v5:
- Improved NOTEs on SBI_PMU_HW_CPU_CYCLES, SBI_PMU_HW_REF_CPU_CYCLES,
and SBI_PMU_HW_BUS_CYCLES events as suggested by Greg Favor
- Re-ordered paramters of sbi_pmu_counter_config_matching() so that
uint64_t parameter is last one
- Added NOTEs for config_flags[3:7] bits which will be used for event
filtering based on privilege mode
- Allow sbi_pmu_counter_start() and sbi_pmu_counter_stop() to work on
a set of counters
- Re-ordered function numbering to make sbi_pmu_counter_fw_read() as
last function
Changes since v4:
- Simplified "NOTE" section for RAW events
- Resized tables
- Added "SBI version" column to function list table
- Added "NOTE" section for SBI_PMU_HW_BUS_CYCLES and SBI_PMU_HW_REF_CPU_CYCLE
- Explicity mention that event_data is 64 bits wide
- Only lower 56 bits of event_data are used for RAW events to align with
upcoming Sscof extension
Changes since v3:
- The new "sscof" extension requires the event info to be 64 bit.
- Improves:
1. the counter start/stop function ids with a appropriate error codes
2. An additional flag parameter to accomodate "sscof extension".
- Renames:
a. software counter to firmware counter to avoid ambiguity with
kernel software events.
b. event_info to event_data to avoid ambiguity with counter info
---
riscv-sbi.adoc | 458 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 458 insertions(+)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index 16b7380..7eadb44 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -34,6 +34,7 @@ https://creativecommons.org/licenses/by/4.0/.
* Improved SBI introduction secion
* Improved documentation of SBI hart state managment extension
* Added suspend function to SBI hart state managment extension
+* Added performance monitoring unit extension

=== Version 0.2

@@ -114,6 +115,8 @@ error codes.
| SBI_ERR_DENIED | -4
| SBI_ERR_INVALID_ADDRESS | -5
| SBI_ERR_ALREADY_AVAILABLE | -6
+| SBI_ERR_ALREADY_STARTED | -7
+| SBI_ERR_ALREADY_STOPPED | -8
|===

An `ECALL` with an unsupported SBI extension ID (*EID*) or an unsupported SBI
@@ -1092,6 +1095,461 @@ The possible error codes returned in `sbiret.error` are shown in the
| sbi_system_reset | 0.3 | 0 | 0x53525354
|===

+== Performance Monitoring Unit Extension (EID #0x504D55 "PMU")
+
+The RISC-V hardware performance counters such as `mcycle`, `minstret`, and
+`mhpmcounterX` CSRs are accessible as read-only from supervisor-mode using
+`cycle`, `instret`, and `hpmcounterX` CSRs. The SBI performance monitoring
+unit (PMU) extension is an interface for supervisor-mode to configure and
+use the RISC-V hardware performance counters with assistance from the
+machine-mode (or hypervisor-mode). These hardware performance counters
+can only be started, stopped, or configured from machine-mode using
+`mcountinhibit` and `mhpmeventX` CSRs. Due to this, a machine-mode SBI
+implementation may choose to disallow SBI PMU extension if `mcountinhibit`
+CSR is not implemented by the RISC-V platform.
+
+A RISC-V platform generally supports monitoring of various hardware events
+using a limited number of hardware performance counters which are up to
+64 bits wide. In addition, a SBI implementation can also provide firmware
+performance counters which can monitor firmware events such as number of
+misaligned load/store instructions, number of RFENCEs, number of IPIs, etc.
+The firmware counters are always 64 bits wide.
+
+The SBI PMU extension provides:
+
+1. An interface for supervisor-mode software to discover and configure
+ per-HART hardware/firmware counters
+2. A typical https://en.wikipedia.org/wiki/Perf_(Linux)[perf] compatible
+ interface for hardware/firmware performance counters and events
+3. Full access to microarchitecture's raw event encodings
+
+To define SBI PMU extension calls, we first define important entities
+`counter_idx`, `event_idx`, and `event_data`. The `counter_idx` is a
+logical number assigned to each hardware/firmware counter. The `event_idx`
+represents a hardware (or firmware) event whereas the `event_data` is
+64 bits wide and represents additional configuration (or parameters) for
+a hardware (or firmware) event.
+
+The event_idx is a 20 bits wide number encoded as follows:
+[source, C]
+----
+ event_idx[19:16] = type
+ event_idx[15:0] = code
+----
+
+=== Event: Hardware general events (Type #0)
+
+The `event_idx.type` (i.e. *event type*) should be `0x0` for all hardware
+general events and each hardware general event is identified by an unique
+`event_idx.code` (i.e. *event code*) described in the
+<<table_pmu_hardware_events>> below.
+
+[#table_pmu_hardware_events]
+.PMU Hardware Events
+[cols="6,1,4", width=95%, align="center", options="header"]
+|===
+| General Event Name | Code | Description
+| SBI_PMU_HW_NO_EVENT | 0 | Unused event because
+ `event_idx` cannot be zero
+| SBI_PMU_HW_CPU_CYCLES | 1 | Event for each CPU cycle
+| SBI_PMU_HW_INSTRUCTIONS | 2 | Event for each completed
+ instruction
+| SBI_PMU_HW_CACHE_REFERENCES | 3 | Event for cache hit
+| SBI_PMU_HW_CACHE_MISSES | 4 | Event for cache miss
+| SBI_PMU_HW_BRANCH_INSTRUCTIONS | 5 | Event for a branch instruction
+| SBI_PMU_HW_BRANCH_MISSES | 6 | Event for a branch misprediction
+| SBI_PMU_HW_BUS_CYCLES | 7 | Event for each BUS cycle
+| SBI_PMU_HW_STALLED_CYCLES_FRONTEND | 8 | Event for a stalled cycle in
+ microarchitecture frontend
+| SBI_PMU_HW_STALLED_CYCLES_BACKEND | 9 | Event for a stalled cycle in
+ microarchitecture backend
+| SBI_PMU_HW_REF_CPU_CYCLES | 10 | Event for each reference
+ CPU cycle
+|===
+
+*NOTE:* The `event_data` (i.e. *event data*) is unused for hardware
+general events and all non-zero values of `event_data` are reserved
+for future use.
+
+*NOTE:* The *SBI_PMU_HW_CPU_CYCLES* event counts CPU clock cycles as
+counted by the `cycle` CSR. These may be variable frequency cycles, and
+are not counted when the CPU clock is halted (i.e. WAIT state entered
+using WFI instruction or platform specific SUSPEND state entered using
+the SBI HSM HART suspend call).
+
+*NOTE:* The *SBI_PMU_HW_REF_CPU_CYCLES* counts fixed-frequency clock
+cycles while the CPU clock is not halted (i.e. WAIT state entered using
+WFI instruction or platform specific SUSPEND state entered SBI HSM HART
+suspend call). The fixed-frequency of counting might, for example, be
+the same frequency at which the `mtime` CSR counts.
+
+*NOTE:* The *SBI_PMU_HW_BUS_CYCLES* counts fixed-frequency clock cycles.
+The fixed-frequency of counting might be the same frequency at which the
+`mtime` CSR counts, or may be the frequency of the clock at the boundary
+between the HART (and it's private caches) and the rest of the system.
+
+=== Event: Hardware cache events (Type #1)
+
+The `event_idx.type` (i.e. *event type*) should be `0x1` for all hardware
+cache events and each hardware cache event is identified by an unique
+`event_idx.code` (i.e. *event code*) which is encoded as follows:
+
+[source, C]
+----
+ event_idx.code[15:3] = cache_id
+ event_idx.code[2:1] = op_id
+ event_idx.code[0:0] = result_id
+----
+
+Below tables show possible values of: `event_idx.code.cache_id` (i.e.
+*cache event id*), `event_idx.code.op_id` (i.e. *cache operation id*)
+and `event_idx.code.result_id` (i.e. *cache result id*).
+
+[#table_pmu_cache_event_id]
+.PMU Cache Event ID
+[cols="6,2,4", width=95%, align="center", options="header"]
+|===
+| Cache Event Name | Event ID | Description
+| SBI_PMU_HW_CACHE_L1D | 0 | Level1 data cache event
+| SBI_PMU_HW_CACHE_L1I | 1 | Level1 instruction cache event
+| SBI_PMU_HW_CACHE_LL | 2 | Last level cache event
+| SBI_PMU_HW_CACHE_DTLB | 3 | Data TLB event
+| SBI_PMU_HW_CACHE_ITLB | 4 | Instruction TLB event
+| SBI_PMU_HW_CACHE_BPU | 5 | Branch predictor unit event
+| SBI_PMU_HW_CACHE_NODE | 6 | NUMA node cache event
+|===
+
+[#table_pmu_cache_ops_id]
+.PMU Cache Operation ID
+[cols="6,2,4", width=95%, align="center", options="header"]
+|===
+| Cache Operation Name | Operation ID | Description
+| SBI_PMU_HW_CACHE_OP_READ | 0 | Read cache line
+| SBI_PMU_HW_CACHE_OP_WRITE | 1 | Write cache line
+| SBI_PMU_HW_CACHE_OP_PREFETCH | 2 | Prefetch cache line
+|===
+
+[#table_pmu_cache_result_id]
+.PMU Cache Operation Result ID
+[cols="6,2,4", width=95%, align="center", options="header"]
+|===
+| Cache Result Name | Result ID | Description
+| SBI_PMU_HW_CACHE_RESULT_ACCESS | 0 | Cache access
+| SBI_PMU_HW_CACHE_RESULT_MISS | 1 | Cache miss
+|===
+
+*NOTE:* The `event_data` (i.e. *event data*) is unused for hardware cache
+events and all non-zero values of `event_data` are reserved for future use.
+
+=== Event: Hardware raw events (Type #2)
+
+The `event_idx.type` (i.e. *event type*) should be `0x2` for all hardware
+raw events and `event_idx.code` (i.e. *event code*) should be zero. The
+`event_data` configuration (or parameter) should have the 56 bits wide
+non-zero event value to be programmed in the `mhpmeventX` CSR. The upper
+8 bits of `event_data` are unused and all non-zero values of these bits
+are reserved for future use.
+
+*Note:* Platform may choose to define the expected value to be written to
+`mhpmeventX` CSR for a hardware event. In case of a hardware general/cache
+events, platform may use the zero-extended `event_idx` as the expected
+value for simplicity.
+
+=== Event: Firmware events (Type #15)
+
+The `event_idx.type` (i.e. *event type*) should be `0xf` for all firmware
+events and each firmware event is identified by an unqiue `event_idx.code`
+(i.e. *event code*) described in the <<table_pmu_firmware_events>> below.
+
+[#table_pmu_firmware_events]
+.PMU Firmware Events
+[cols="6,1,4", width=95%, align="center", options="header"]
+|===
+| Firmware Event Name | Code | Description
+| SBI_PMU_FW_MISALIGNED_LOAD | 0 | Misaligned load trap event
+| SBI_PMU_FW_MISALIGNED_STORE | 1 | Misaligned store trap event
+| SBI_PMU_FW_ACCESS_LOAD | 2 | Load access trap event
+| SBI_PMU_FW_ACCESS_STORE | 3 | Store access trap event
+| SBI_PMU_FW_ILLEGAL_INSN | 4 | Illegal instruction trap event
+| SBI_PMU_FW_SET_TIMER | 5 | Set timer event
+| SBI_PMU_FW_IPI_SENT | 6 | Sent IPI to other HART event
+| SBI_PMU_FW_IPI_RECEIVED | 7 | Received IPI from other
+ HART event
+| SBI_PMU_FW_FENCE_I_SENT | 8 | Sent FENCE.I request to
+ other HART event
+| SBI_PMU_FW_FENCE_I_RECEIVED | 9 | Received FENCE.I request
+ from other HART event
+| SBI_PMU_FW_SFENCE_VMA_SENT | 10 | Sent SFENCE.VMA request
+ to other HART event
+| SBI_PMU_FW_SFENCE_VMA_RECEIVED | 11 | Received SFENCE.VMA request
+ from other HART event
+| SBI_PMU_FW_SFENCE_VMA_ASID_SENT | 12 | Sent SFENCE.VMA with ASID
+ request to other HART event
+| SBI_PMU_FW_SFENCE_VMA_ASID_RECEIVED | 13 | Received SFENCE.VMA with ASID
+ request from other HART event
+| SBI_PMU_FW_HFENCE_GVMA_SENT | 14 | Sent HFENCE.GVMA request to
+ other HART event
+| SBI_PMU_FW_HFENCE_GVMA_RECEIVED | 15 | Received HFENCE.GVMA request
+ from other HART event
+| SBI_PMU_FW_HFENCE_GVMA_VMID_SENT | 16 | Sent HFENCE.GVMA with VMID
+ request to other HART event
+| SBI_PMU_FW_HFENCE_GVMA_VMID_RECEIVED | 17 | Received HFENCE.GVMA with VMID
+ request from other HART event
+| SBI_PMU_FW_HFENCE_VVMA_SENT | 18 | Sent HFENCE.VVMA request to
+ other HART event
+| SBI_PMU_FW_HFENCE_VVMA_RECEIVED | 19 | Received HFENCE.VVMA request
+ from other HART event
+| SBI_PMU_FW_HFENCE_VVMA_ASID_SENT | 20 | Sent HFENCE.VVMA with ASID
+ request to other HART event
+| SBI_PMU_FW_HFENCE_VVMA_ASID_RECEIVED | 21 | Received HFENCE.VVMA with ASID
+ request from other HART event
+|===
+
+*NOTE:* the `event_data` (i.e. *event data*) is unused for firmware events
+and all non-zero values of `event_data` are reserved for future use.
+
+=== Function: Get number of counters (FID #0)
+
+[source, C]
+----
+struct sbiret sbi_pmu_num_counters()
+----
+
+*Returns* the number of counters (both hardware and firmware) in
+`sbiret.value` and always returns `SBI_SUCCESS` in sbiret.error.
+
+=== Function: Get details of a counter (FID #1)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_get_info(unsigned long counter_idx)
+----
+
+Get details about the specified counter such as underlying CSR number,
+width of the counter, type of counter hardware/firmware, etc.
+
+The `counter_info` returned by this SBI call is encoded as follows:
+[source, C]
+----
+ counter_info[11:0] = CSR (12bit CSR number)
+ counter_info[17:12] = Width (One less than number of bits in CSR)
+ counter_info[XLEN-2:18] = Reserved for future use
+ counter_info[XLEN-1] = Type (0 = hardware and 1 = firmware)
+----
+
+If `counter_info.type == 1` then `counter_info.csr` and `counter_info.width`
+should be ignored.
+
+*Returns* the `counter_info` described above in `sbiret.value`.
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_get_info_errors>> below.
+
+[#table_pmu_counter_get_info_errors]
+.PMU Counter Get Info Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code | Description
+| SBI_SUCCESS | `counter_info` read successfully.
+| SBI_ERR_INVALID_PARAM | `counter_idx` points to an invalid counter.
+|===
+
+=== Function: Find and configure a matching counter (FID #2)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_config_matching(unsigned long counter_idx_base,
+ unsigned long counter_idx_mask,
+ unsigned long config_flags,
+ unsigned long event_idx,
+ uint64_t event_data)
+----
+
+Find and configure a counter from a set of counters which is not started
+(or enabled) and can monitor the specified event. The `counter_idx_base`
+and `counter_idx_mask` parameters represent the set of counters whereas
+the `event_idx` represent the event to be monitored and `event_data`
+represents any additional event configuration.
+
+The `config_flags` parameter represent additional counter configuration
+and filter flags. The bit defintions of the `config_flags` parameter are
+shown in the <<table_pmu_counter_cfg_match_flags>> below.
+
+[#table_pmu_counter_cfg_match_flags]
+.PMU Counter Config Match Flags
+[cols="3,1,2", width=90%, align="center", options="header"]
+|===
+| Flag Name | Bits | Description
+| SBI_PMU_CFG_FLAG_SKIP_MATCH | 0:0 | Skip the counter matching
+| SBI_PMU_CFG_FLAG_CLEAR_VALUE| 1:1 | Clear (or zero) the counter
+ value in counter configuration
+| SBI_PMU_CFG_FLAG_AUTO_START | 2:2 | Start the counter after
+ configuring a matching counter
+| SBI_PMU_CFG_FLAG_SET_MINH | 3:3 | Event counting inhibited +
+ in M-mode
+| SBI_PMU_CFG_FLAG_SET_SINH | 4:4 | Event counting inhibited +
+ in S-mode
+| SBI_PMU_CFG_FLAG_SET_UINH | 5:5 | Event counting inhibited +
+ in U-mode
+| SBI_PMU_CFG_FLAG_SET_VSINH | 6:6 | Event counting inhibited +
+ in VS-mode
+| SBI_PMU_CFG_FLAG_SET_VUINH | 7:7 | Event counting inhibited +
+ in VU-mode
+| *RESERVED* | 8:(XLEN-1) | All non-zero values are
+ reserved for future use
+|===
+
+*NOTE:* When *SBI_PMU_CFG_FLAG_SKIP_MATCH* is set in `config_flags`, the
+SBI implementation will unconditionaly select the first counter from the
+set of counters specified by the `counter_idx_base` and `counter_idx_mask`.
+
+*NOTE:* The *SBI_PMU_CFG_FLAG_AUTO_START* flag in `config_flags` has no
+impact on the counter value.
+
+*NOTE:* The `config_flags[3:7]` bits are event filtering hints so these
+can be ignored or overriden by the SBI implemenation for security concerns
+or due to lack of event filtering support in underlying platform.
+
+*Returns* the `counter_idx` in `sbiret.value` upon success.
+
+In case of failure, the possible error codes returned in `sbiret.error` are
+shown in the <<table_pmu_counter_cfg_match_errors>> below.
+
+[#table_pmu_counter_cfg_match_errors]
+.PMU Counter Config Match Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code | Description
+| SBI_SUCCESS | counter found and configured successfully.
+| SBI_ERR_INVALID_PARAM | set of counters has an invalid counter.
+| SBI_ERR_NOT_SUPPORTED | none of the counters can monitor specified event.
+|===
+
+=== Function: Start a set of counters (FID #4)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_start(unsigned long counter_idx_base,
+ unsigned long counter_idx_mask,
+ unsigned long start_flags,
+ uint64_t initial_value)
+----
+
+Start or enable a sef of counters on the calling HART with the specified
+initial value. The `counter_idx_base` and `counter_idx_mask` parameters
+represent the set of counters whereas the `initial_value` parameter
+specifies the initial value of the counter.
+
+The bit defintions of the `start_flags` parameter are shown in the
+<<table_pmu_counter_start_flags>> below.
+
+[#table_pmu_counter_start_flags]
+.PMU Counter Start Flags
+[cols="3,1,2", width=90%, align="center", options="header"]
+|===
+| Flag Name | Bits | Description
+| SBI_PMU_START_SET_INIT_VALUE | 0:0 | Set the value of counters
+ based on the `initial_value`
+ parameter
+| *RESERVED* | 1:(XLEN-1) | All non-zero values are
+ reserved for future use
+|===
+
+*NOTE:* When SBI_PMU_START_SET_INIT_VALUE is not set in `start_flags`,
+the counter value will not be modified and event counting will start
+from current counter value.
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_start_errors>> below.
+
+[#table_pmu_counter_start_errors]
+.PMU Counter Start Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code | Description
+| SBI_SUCCESS | counter started successfully.
+| SBI_ERR_INVALID_PARAM | some of the counters specified in parameters
+ are invalid.
+| SBI_ERR_ALREADY_STARTED | some of the counters specified in parameters
+ are already started.
+|===
+
+=== Function: Stop a set of counters (FID #4)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_stop(unsigned long counter_idx_base,
+ unsigned long counter_idx_mask,
+ unsigned long stop_flags)
+----
+
+Stop or disable a set of counters on the calling HART. The `counter_idx_base`
+and `counter_idx_mask` parameters represent the set of counters. The bit
+defintions of the `stop_flags` parameter are shown in the
+<<table_pmu_counter_stop_flags>> below.
+
+[#table_pmu_counter_stop_flags]
+.PMU Counter Stop Flags
+[cols="3,1,2", width=90%, align="center", options="header"]
+|===
+| Flag Name | Bits | Description
+| SBI_PMU_STOP_FLAG_RESET | 0:0 | Reset the counter to event mapping.
+| *RESERVED* | 1:(XLEN-1) | All non-zero values are reserved
+ for future use
+|===
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_stop_errors>> below.
+
+[#table_pmu_counter_stop_errors]
+.PMU Counter Stop Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code | Description
+| SBI_SUCCESS | counter stopped successfully.
+| SBI_ERR_INVALID_PARAM | some of the counters specified in parameters
+ are invalid.
+| SBI_ERR_ALREADY_STOPPED | some of the counters specified in parameters
+ are already stopped.
+|===
+
+=== Function: Read a firmware counter (FID #5)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_fw_read(unsigned long counter_idx)
+----
+
+Provide the current value of a firmware counter in `sbiret.value`.
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_fw_read_errors>> below.
+
+[#table_pmu_counter_fw_read_errors]
+.PMU Counter Firmware Read Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code | Description
+| SBI_SUCCESS | firmware counter read successfully.
+| SBI_ERR_INVALID_PARAM | `counter_idx` points to a hardware counter
+ or an invalid counter.
+|===
+
+=== Function Listing
+
+[#table_pmu_function_list]
+.PMU Function List
+[cols="5,2,1,2", width=80%, align="center", options="header"]
+|===
+| Function Name | SBI Version | FID | EID
+| sbi_pmu_num_counters | 0.3 | 0 | 0x504D55
+| sbi_pmu_counter_get_info | 0.3 | 1 | 0x504D55
+| sbi_pmu_counter_config_matching | 0.3 | 2 | 0x504D55
+| sbi_pmu_counter_start | 0.3 | 3 | 0x504D55
+| sbi_pmu_counter_stop | 0.3 | 4 | 0x504D55
+| sbi_pmu_counter_fw_read | 0.3 | 5 | 0x504D55
+|===
+
== Experimental SBI Extension Space (EIDs #0x08000000 - #0x08FFFFFF)

No management.
--
2.25.1


Re: [PATCH v5 0/2] System Peripherals

Mayuresh Chitale
 

Atish, Johnathan,

Please let me know if any further changes are required.

Thanks,
Mayuresh.


On Fri, May 21, 2021 at 2:11 PM Mayuresh Chitale via lists.riscv.org <mchitale=ventanamicro.com@...> wrote:
This patch describes requirements for the system peripherals
like UART, clock and timers for the Linux-2022 platform
base spec and the server extension.

Changes in V5:
  - Rebased on main

Changes in V4:
  - Rephrased the requirement for minimum counter resolution

Changes in V3:

Base spec:
  - Clarified minimum requirement for counter resolution.

Server extension:
  - Removed watchdog timers section which to be moved into a separate patch.

Changes in V2:

Rephrased the requirements to use 'required' keyword instead of 'shall'.

Base spec:
  UART:
    - Added 8250 as deprecated and 16550 as mandatory

  Clock and Timers:
    - Move time csr, sstc requirement to server extension

Server extension:
  - Added Clock and Timers requirements
  - Added implementation notes for clock and watchdog timers

Changes in V1:
 - Initial draft for base spec only.

Mayuresh Chitale (2):
  Updating contributors
  System Peripherals: Linux 2022 Base spec and server extension

 contributors.adoc        |  3 ++-
 riscv-platform-spec.adoc | 43 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 42 insertions(+), 4 deletions(-)

--
2.17.1







[PATCH v5 2/2] System Peripherals: Linux 2022 Base spec and server extension

Mayuresh Chitale
 

Base spec:
- UART
- Clock and Timers

Server extension:
- Clock and Timers

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
riscv-platform-spec.adoc | 43 +++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 98783c8..4418788 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -85,10 +85,40 @@ include::profiles.adoc[]

==== System Peripherals
* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers

+In order to facilitate the bringup and debug of the low level initial platform
+software(firmware, bootloaders, kernel etc), platforms are required to
+implement a UART port which confirms to the following requirements:
+
+* The UART register addresses are required to be aligned to 4 byte boundaries.
+If the implemented register width is less than 4 bytes then the implmented
+bytes are required to be mapped starting at the smallest address.
+* The UART port implementation is required to be register-compatible with one
+of the following:
+** UART 16550 - _REQUIRED_
+** UART 8250 - _DEPRECATED_
+
+* Clock and Timers
+** Platforms are required to provide an at least 10ns resolution 64-bit counter
+with strictly monotonic updates.
+** The hardware clock that drives the counter is required to operate at a minimum
+frequency of 10MHz.
+** Platforms that use DT for hardware discovery are required to advertise the
+timebase to the operating systems via the `timebase-frequency` property of the
+"/cpus" node
+footnote:[https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/riscv/cpus.yaml].
+
+[sidebar]
+--
+[underline]*_Implementation Note_*
+
+For a counter with 10ns resolution the `timebase-frequency` value would be 100000000
+(100 MHz) which would also be the minimum possible value for `timebase-frequency`.
+From the software perspective a unit increment of the mtime value would correspond
+to a 10ns interval. However the hardware clock driving the counter could operate at a
+lower frequency, thereby incrementing the mtime value by more than one unit per
+clock tick.
+--
==== Boot Process
- The base specification defines the interface between the firmware and the
operating system suitable for the RISC-V platforms with rich operating
@@ -326,6 +356,13 @@ implemented but it can return EFI_UNSUPPORTED.
|===

==== System Peripherals
+* Clock and Timers
+** Platforms are required to implement the time CSR.
+** Platforms are required to implement the
+https://lists.riscv.org/g/tech-privileged/message/404[Sstc] extension.
+** Platforms are required to delegate the supervisor timer interrupt to 'S'
+mode. If the 'H' extension is implemented then the platforms are required to
+delegate the virtual supervisor timer interrupt to 'VS' mode.
* PCI-E

==== Secure Boot
--
2.17.1

881 - 900 of 1847