1. tech-unixplatformspec@lists.riscv.org
  2. Messages
   Date   
[PATCH v1 2/2] Platform debug requirements

Paul Donahue
 

Signed-off-by: Paul Donahue pdonahue@...
---
riscv-platform-spec.adoc | 101 +++++++++++++++++++++++++++++++++++++++
1 file changed, 101 insertions(+)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 98783c8..e5a1236 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -73,6 +73,93 @@ include::profiles.adoc[]
** ASID
* Debug
+==== Debug
+The Linux base platform requirements are -
+
+- Implement resethaltreq
+ * Rationale: Debugging immediately out of reset is a useful debug tool and
+ is required by item 5 in chapter 3. The resethaltreq mechanism provides a
+ standard way to do this.
+- Implement the program buffer
+ * Rationale: The program buffer is easier for most implementations than
+ abstract access.
+ * Rationale: Debuggers need to be able to insert ebreak instructions into
+ memory and make sure that the ebreak is visible to subsequent instruction
+ fetches. Abstract access has no support for fence.i (or similar
+ mechanisms).
+- abstractcs.relaxedpriv must be 0
+ * Rationale: Doing otherwise is a potential security problem.
+- abstractauto must be implemented
+ * Rationale: autoexecprogbuf allows faster instruction-stuffing
+ * Rationale: autoexecdata allows fast read/write of a region of memory
+- dcsr.mprven must be tied to 1
+ * Rationale: Emulating two-stage table walks and PMP checks and endianness
+ swapping is a heavy burden on the debugger.
+- In textra, sselect must support the value 0 and either value 1 or 2 (or
+both).
+ * Rationale: There must be some way to limit triggers to only match in a
+ particular user context and a way to ignore user context.
+- If textra.sselect=1 is supported, the number of implemented bits of svalue
+must be at least the number of implemented bits of scontext.
+ * Rationale: This allows matching on every possible scontext.
+- If textra.sselect=2 is supported, the number of implemented bits of svalue
+must be at least ASIDLEN.
+ * Rationale: This allows matching on every possible ASID.
+- In textra, mhselect must support the value 0. If the H extension is
+supported then mhselect must also support either values 1 and 5 or values 2
+and 6 (or all four).
+ * Rationale: There must be some way to limit triggers to only match in a
+ particular guest context and a way to ignore guest context.
+- If textra.mhselect=1,5 are supported and if H is the number of implemented
+bits of hcontext then, unless all bits of mhvalue are implemented, at least
+H-1 bits of mhvalue must be implemented.
+ * Rationale: This allows matching on every possible hcontext (up to the limit
+ of the field width). It is H-1 bits instead of H because mhselect[2]
+ provides one bit.
+- If textra.mhselect=2,6 are supported, the number of implemented bits of
+mhvalue must be at least VMIDLEN-1.
+ * Rationale: This allows matching on every possible VMID. It is VMIDLEN-1
+ instead of VMIDLEN because mhselect[2] provides one bit.
+- Implement at least four mcontrol6 triggers that can support matching on PC
+(select=0, execute=1, match=0) with timing=0 and full support for mode
+filtering (vs, vu, m, s, u) for all supported modes and support for textra as
+above.
+ * Rationale: The debugger needs breakpoints and 4 is a sufficient baseline.
+- Implement at least four mcontrol6 triggers that can support matching on load
+ and store addresses (select=0, match=0, and all combinations of load/store)
+ with timing=0 and full support for mode filtering (vs, vu, m, s, u) for all
+ supported modes and support for textra as above.
+ * Rationale: The debugger needs watchpoints and 4 is a sufficient baseline.
+- Implement at least one trigger capable of icount and support for textra as
+above.
+ * Rationale: Self-hosted single step needs this
+- Implement at least one trigger capable of etrigger and support for textra as
+above.
+ * Rationale: Debuggers need to be able to catch exceptions.
+- Implement at least one trigger capable of itrigger and support for textra as
+above.
+ * Rationale: Debuggers need to be able to catch interrupts.
+- The minimum trigger requirements must be met for action=0 and for action=1
+(possibly by the same triggers)
+ * Rationale: The intent is to have full support for external debug and full
+ support for self-hosted debug (though not necessarily at the same time).
+ This can be provided via the same set of triggers or separate sets of
+ triggers. External debug support for icount is unnecessary due to dcsr.step
+ and is therefore called out separately.
+- For implementations with multiple cores, support for at least one halt group
+and one resume group (in addition to group 0)
+ * Rationale: Allows stopping all harts (approximately) simultaneously which
+ is useful for debugging MP software
+- dcsr.stepie must support the 0 setting. It is optional to support the 1
+setting.
+ * Rationale: It is not generally useful to step into interrupt
handlers.
+- dcsr.stopcount and dcsr.stoptime must be supported and the reset value of
+each must be 1
+ * Rationale: The architecture has strict requirements on minstret which may
+ be perturbed by an external debugger in a way that's visible to software.
+ The default should allow code that's sensitive to these requirements to be
+ debugged.
+
==== Memory Map
* Virtual Memory
* sv39/sv48/sv57
@@ -166,6 +253,20 @@ Spec should be ratified*]
file for each HART ?? (*TBD*)
- IOMMU with support for memory resident interrupt files ?? (*TBD*)
+==== Debug
+The Linux server platform requirements are all of the above plus:
+
+- Implement at least six mcontrol6 triggers that can support matching on PC
+(select=0, execute=1, match=0) with timing=0 and full support for mode
+filtering (vs, vu, m, s, u) for all supported modes and support for textra as
+above.
+ * Rationale: Other architectures have found that 4 breakpoints are
+ insufficient in more capable systems and recommend 6.
+- If system bus access is implemented then accesses must be coherent with
+respect to all harts connected to the DM
+ * Rationale: Debuggers must be able to view memory coherently
+
+
==== Boot and Runtime Requirements
===== Firmware
The boot and system firmware for the RV64I server platforms required to be
--
2.25.1
[PATCH v1 1/2] Updating changelog

Paul Donahue
 

Updating changelog

Signed-off-by: Paul Donahue pdonahue@...
---
changelog.adoc | 2 ++
1 file changed, 2 insertions(+)

diff --git a/changelog.adoc b/changelog.adoc
index 7ec1b1f..cc69971 100644
--- a/changelog.adoc
+++ b/changelog.adoc
@@ -8,6 +8,8 @@
## Change Log
### version 0.2-rc0
+* 2021-05-20:
+** Platform requirements for Debug
* 2021-05-19:
** Base boot and runtime requirements - Initial commit
* 2021-04-08:
--=20
2.25.1
[PATCH v1 0/2] Updating contributors

Paul Donahue
 

Adding myself to list of contributors.

Signed-off-by: Paul Donahue pdonahue@...
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index 08b16f0..13dcf59 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -27,7 +27,8 @@ Andrew Waterman,
Kumar Sankaran,
Alistair Francis,
Sunil V L,
-Rahul Pathak
+Rahul Pathak,
+Paul Donahue
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.25.1
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Josh Scheid
 

On Fri, May 28, 2021 at 4:07 PM Jonathan Behrens <behrensj@...> wrote:

The main issue I see with the mtime synchronization code sample in the linked spec is that it doesn't do anything to address clock drift. The linked paper claims that CPU clocks can drift by 10 microseconds/second or more, so unless you have dedicated hardware to prevent drift (in which case why are you bothering with software at all?) you are very rapidly going to observe time readings that differ by more than one tick even if they start out consistent.
_._,_._,

At least at the platform level, the requirement of a single reference clock for all timers in a "system" (thus preventing first-order drift) may be a desirable requirement.

-Josh
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Jonathan Behrens <behrensj@...>
 

If you're interested in reading about pure software approaches to clock synchronization, I recommend looking at https://www.usenix.org/conference/nsdi18/presentation/geng. They focus on synchronizing clocks between different servers in the same datacenter which if anything is a harder problem.

The main issue I see with the mtime synchronization code sample in the linked spec is that it doesn't do anything to address clock drift. The linked paper claims that CPU clocks can drift by 10 microseconds/second or more, so unless you have dedicated hardware to prevent drift (in which case why are you bothering with software at all?) you are very rapidly going to observe time readings that differ by more than one tick even if they start out consistent.

Jonathan


On Fri, May 28, 2021 at 5:44 PM Josh Scheid via lists.riscv.org <jscheid=ventanamicro.com@...> wrote:
One other issue with the "mtime" synchronization by SW approach is that this effectively places an upper limit on the achievable timer unit resolution.  It'd be some equation based on the ordered access latency of the reference and target resources, perhaps.

Has this been explicitly considered?  What is the expected upper limit and where should the platform be moving towards in the future?  Would further work be needed to enable >=1GHz timer resolution?

-Josh
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Greg Favor
 

On Fri, May 28, 2021 at 2:44 PM Josh Scheid <jscheid@...> wrote:
One other issue with the "mtime" synchronization by SW approach is that this effectively places an upper limit on the achievable timer unit resolution.  It'd be some equation based on the ordered access latency of the reference and target resources, perhaps.

Has this been explicitly considered?  What is the expected upper limit and where should the platform be moving towards in the future?  Would further work be needed to enable >=1GHz timer resolution?

More recent ARM SBSA requires a 1 GHz counter resolution, but does not place any requirement on the actual measurable 'time" resolution (i.e. a minimum update frequency).  So one can have 1 ns resolution in the 'time' counter value, but the actual measurable granularity could be just 1 us.

Upping the standard counter resolution seems of little or secondary value.  It's the actual maximum granularity or resolution of measurable time that matters.  Which no one in RISC-V (or ARM SBSA) seems willing or wanting to require actual 1 ns resolution to time measurements.

Greg
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Josh Scheid
 

One other issue with the "mtime" synchronization by SW approach is that this effectively places an upper limit on the achievable timer unit resolution.  It'd be some equation based on the ordered access latency of the reference and target resources, perhaps.

Has this been explicitly considered?  What is the expected upper limit and where should the platform be moving towards in the future?  Would further work be needed to enable >=1GHz timer resolution?

-Josh
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Josh Scheid
 

On Thu, May 27, 2021 at 8:05 PM Greg Favor <gfavor@...> wrote:
On Thu, May 27, 2021 at 10:34 AM Neel Gala <neelgala@...> wrote:
Should there be a mention that the user level "time" csr (0xC01) which is used by the rdtime pseudo-instruction will enable a read-only peek into the mtime register? Would this require change in Table-1 privilege mode accesses? as well?

Architecturally the 'time' CSR reads the same concept of "time" as the 'mtime' register.  Simplistically the RDTIME pseudoinstruction reads what is in the 'mtime' register.  One implementation is that each hart has a local copy of 'mtime' that is available to be read by RDTIME (in other words, copies of 'mtime' are distributed in hardware to each hart - to appear as the 'time' CSR inside each hart).  Another implementation is to trap and emulate RDTIME using a read of the memory-mapped 'mtime' register.  Other implementation approaches are possible.


Note that the "update latency" between a write to "mtime" and a read of the hart-local "time" is unspecified.

-Josh
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Greg Favor
 

On Thu, May 27, 2021 at 10:34 AM Neel Gala <neelgala@...> wrote:
Should there be a mention that the user level "time" csr (0xC01) which is used by the rdtime pseudo-instruction will enable a read-only peek into the mtime register? Would this require change in Table-1 privilege mode accesses? as well?

Architecturally the 'time' CSR reads the same concept of "time" as the 'mtime' register.  Simplistically the RDTIME pseudoinstruction reads what is in the 'mtime' register.  One implementation is that each hart has a local copy of 'mtime' that is available to be read by RDTIME (in other words, copies of 'mtime' are distributed in hardware to each hart - to appear as the 'time' CSR inside each hart).  Another implementation is to trap and emulate RDTIME using a read of the memory-mapped 'mtime' register.  Other implementation approaches are possible.

Greg

Should there also be a suggestion/recommendation on how to disable a pending interrupt (typically by writing to mtimecmp)?
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Neel Gala
 

Hi,

Minor comments:

Should there be a mention that the user level "time" csr (0xC01) which is used by the rdtime pseudo-instruction will enable a read-only peek into the mtime register? Would this require change in Table-1 privilege mode accesses? as well?

Should there also be a suggestion/recommendation on how to disable a pending interrupt (typically by writing to mtimecmp)?

On Thu, May 27, 2021 at 10:45 AM Anup Patel <anup.patel@...> wrote:

Hi Josh,

 

I have created a GitHub PR addressing your comments. Please check if you are okay with this.

https://github.com/riscv/riscv-aclint/pull/2

 

Regards,

Anup

 

From: tech-aia@... <tech-aia@...> On Behalf Of Josh Scheid
Sent: 27 May 2021 01:58
To: Anup Patel <Anup.Patel@...>
Cc: tech-aia@...; tech-unixplatformspec@...; Atish Patra <Atish.Patra@...>; Greg Favor <gfavor@...>; Alistair Francis <Alistair.Francis@...>; Andrew Waterman <andrew@...>; John Hauser <jh.riscv@...>
Subject: Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

 

Thanks for writing this up, Anup.

 

In https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc#24-synchronizing-multiple-mtimer-devices, the SW algorithm should include verifying the reference-target delta, retrying if the delta is out of bounds, and / or reporting failure to verify the synchronization is in bounds.

 

-Josh

 

 

On Tue, May 25, 2021 at 10:18 PM Anup Patel <anup.patel@...> wrote:

Hi All,

The RISC-V ACLINT specification is now hosted on RISC-V GitHub page:
https://github.com/riscv/riscv-aclint
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

Please review this at your end send feedback on AIA/Platform mailing
lists.

The RISC-V ACLINT specification is intended to be small and backward
compatible to the SiFive CLINT specification which makes existing
RISC-V platforms compliant with the RISC-V ACLINT specification.

Overall, from platforms specification perspective it complements
the RISC-V AIA specification by providing IPI and Timer functionality.

A complete functional implementation is available for QEMU RISC-V
along with OpenSBI and Linux RISC-V changes. Please refer, the
riscv_aclint_v1 branch in following repos:
https://github.com/avpatel/qemu.git
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git

To enable ACLINT emulation on QEMU, use "-M virt,aclint=on"
instead of just "-M virt" in your QEMU command line. For now,
QEMU supports ACLINT only for virt machine.

Regards,
Anup








--
Neel Gala
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Anup Patel
 

Hi Josh,

 

I have created a GitHub PR addressing your comments. Please check if you are okay with this.

https://github.com/riscv/riscv-aclint/pull/2

 

Regards,

Anup

 

From: tech-aia@... <tech-aia@...> On Behalf Of Josh Scheid
Sent: 27 May 2021 01:58
To: Anup Patel <Anup.Patel@...>
Cc: tech-aia@...; tech-unixplatformspec@...; Atish Patra <Atish.Patra@...>; Greg Favor <gfavor@...>; Alistair Francis <Alistair.Francis@...>; Andrew Waterman <andrew@...>; John Hauser <jh.riscv@...>
Subject: Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

 

Thanks for writing this up, Anup.

 

In https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc#24-synchronizing-multiple-mtimer-devices, the SW algorithm should include verifying the reference-target delta, retrying if the delta is out of bounds, and / or reporting failure to verify the synchronization is in bounds.

 

-Josh

 

 

On Tue, May 25, 2021 at 10:18 PM Anup Patel <anup.patel@...> wrote:

Hi All,

The RISC-V ACLINT specification is now hosted on RISC-V GitHub page:
https://github.com/riscv/riscv-aclint
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

Please review this at your end send feedback on AIA/Platform mailing
lists.

The RISC-V ACLINT specification is intended to be small and backward
compatible to the SiFive CLINT specification which makes existing
RISC-V platforms compliant with the RISC-V ACLINT specification.

Overall, from platforms specification perspective it complements
the RISC-V AIA specification by providing IPI and Timer functionality.

A complete functional implementation is available for QEMU RISC-V
along with OpenSBI and Linux RISC-V changes. Please refer, the
riscv_aclint_v1 branch in following repos:
https://github.com/avpatel/qemu.git
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git

To enable ACLINT emulation on QEMU, use "-M virt,aclint=on"
instead of just "-M virt" in your QEMU command line. For now,
QEMU supports ACLINT only for virt machine.

Regards,
Anup
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Anup Patel
 

Hi Josh,

 

Indeed, I missed adding text regarding verifying delta and ensuring that it is within bounds. Thanks for pointing.

 

I was thinking that aclint_mtime_sync() function should return the adjustment value (delta) so that high-level caller can try acling_mtime_sync() few times until the returned adjustment (delta) becomes zero (or close to it).

 

Regards,

Anup

 

From: tech-aia@... <tech-aia@...> On Behalf Of Josh Scheid
Sent: 27 May 2021 01:58
To: Anup Patel <Anup.Patel@...>
Cc: tech-aia@...; tech-unixplatformspec@...; Atish Patra <Atish.Patra@...>; Greg Favor <gfavor@...>; Alistair Francis <Alistair.Francis@...>; Andrew Waterman <andrew@...>; John Hauser <jh.riscv@...>
Subject: Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

 

Thanks for writing this up, Anup.

 

In https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc#24-synchronizing-multiple-mtimer-devices, the SW algorithm should include verifying the reference-target delta, retrying if the delta is out of bounds, and / or reporting failure to verify the synchronization is in bounds.

 

-Josh

 

 

On Tue, May 25, 2021 at 10:18 PM Anup Patel <anup.patel@...> wrote:

Hi All,

The RISC-V ACLINT specification is now hosted on RISC-V GitHub page:
https://github.com/riscv/riscv-aclint
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

Please review this at your end send feedback on AIA/Platform mailing
lists.

The RISC-V ACLINT specification is intended to be small and backward
compatible to the SiFive CLINT specification which makes existing
RISC-V platforms compliant with the RISC-V ACLINT specification.

Overall, from platforms specification perspective it complements
the RISC-V AIA specification by providing IPI and Timer functionality.

A complete functional implementation is available for QEMU RISC-V
along with OpenSBI and Linux RISC-V changes. Please refer, the
riscv_aclint_v1 branch in following repos:
https://github.com/avpatel/qemu.git
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git

To enable ACLINT emulation on QEMU, use "-M virt,aclint=on"
instead of just "-M virt" in your QEMU command line. For now,
QEMU supports ACLINT only for virt machine.

Regards,
Anup
Re: [RESEND PATCH v5 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Abner Chang
 



Alistair Francis <Alistair.Francis@...> 於 2021年5月26日 週三 下午6:57寫道：
On Wed, 2021-05-26 at 10:40 +0000, Anup Patel wrote:
> Hi Alistair,
>
> > -----Original Message-----
> > From: tech-unixplatformspec@... <tech-
> > unixplatformspec@...> On Behalf Of Alistair Francis
> > Sent: 26 May 2021 15:48
> > To: renba.chang@...; tech-unixplatformspec@...
> > Cc: sunilvl@...; mchitale@...
> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RESEND PATCH v5 1/2]
> > riscv-
> > platform-spec: PLIC and CLINT for Linux-2022 platform
> >
> > On Wed, 2021-05-26 at 12:57 +0800, renba.chang@... wrote:
> > > From: Abner Chang <renba.chang@...>
> > >
> > > Initial description of PLIC  CLINT section of Linux-2022 platform.
> > >
> > > On v5 commit,
> > > - Remove CLINT from platform spec
> > > - Require ACLINT on Linux2020 platform and have a link to
> > > https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc
> > > .
> > > - Remove Machine mode timer from previous patch because that is in
> > > the
> > > scope of ACLINT
> > > - For Embedded-2022 platform, mention Machine mode timer and refer
> > > to
> > > ACLINT for the definition of registers
> > >
> > > 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 | 52 ++++++++++++++++++------------------
> > > --
> > > --
> > >  1 file changed, 23 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > > index
> > > 160c74a..db6dce3 100644
> > > --- a/riscv-platform-spec.adoc
> > > +++ b/riscv-platform-spec.adoc
> > > @@ -49,9 +49,23 @@ 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[R
> > > ISC-V
> > >  PLIC Specification]
> > > +for the implementation reference of PLIC operation parameters)
> > > +
> > > +===== ACLINT
> > > +Linux-2020 platform requires the Advanced Core Local Interruptor
> > > (ACLINT, refer
> > > +to
> > > https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RI
> > > SC-V
> > >  ACLINT Specification])
> > > +to provide facilities to route inter-processor interrupt and
> > > Machine
> > > mode timer
> > > +interrupt to each RISC-V processor hart.
> > > +
> > > +===== Interrupt Assignments
> > >
> > >  ==== System Peripherals
> > >  * UART/Serial Console
> > > @@ -289,9 +303,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[CL
> > > IC]
> > > +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[CL
> > > IC]
> > >  or both a CLIC and and PLIC.
> > >
> > >  If using just a PLIC the system must continue to use the original
> > > basic @@ -303,8 +316,8 @@ 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
> > > +==== Machine Mode Timer
> > > +The RISC-V Machine mode timer (controlled via `mtime` and
> > > `mtimecmp`) must be
> > >  implemented. The two registers must be memory mapped as required
> > > by
> > > the RISC-V
> > >  specification.
> > >
> > > @@ -314,27 +327,8 @@ 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 |
> > > -===========================
> >
> > You have removed the original  example, but not the original
> > description. If we
> > aren't supporting the adjancent addresses the paragraph above this
> > should be
> > removed.
> >
> > I still prefer to allow either adjacent registers (as currently
> > described) OR the new ACLINT, but if everyone else thinks the ACLINT
> > is the
> > only way to go then that's fine.
>
> The ACLINT MTIMER register organization is intentionally kept
> compatible
> with CLINT timer registers so that ACLINT is backward compatible.

Yep that's great for Linux systems. I haven't seen any embedded systems
besides SiFive that use the CLINT though.

For example SweRVolf uses a specific system controller:
https://github.com/chipsalliance/Cores-SweRVolf/#system-controller

and OpenTitan has it's own timer:
https://docs.opentitan.org/hw/ip/rv_timer/doc/

The ESP32 doesn't even include mtime so that's a different problem.

>
> If you want a different register layout then this has to be defined
> somewhere. The hardware cost of organizing registers like CLINT
> is not much so it's difficult to justify why we want to organize
> registers differently.

For devices that define their own timer I agree that arranging them
like the CLINT shouldn't be a problem. For ones that include the
mtime/mtimecmp in an other system controller I'm worried they will
instead just not try and meet the embedded spec.

We have already defined the layout here, so I don't think it requires
any more work. I agree 100% that it's more of a burden for software to
support two possible timer layouts, but if HW vendors don't opt to
follow the spec then we have to support a lot more.

Anyway, I'm not completely against only allowing ACLINT, I just wanted
to put it out there that it might be difficult for some vendors to
meet. We aren't requiring use of the PLIC or CLIC so it seems a little
strange to then mandate the ACLINT.
 
Alistair,
I can understand your concern just like I have to the server extension. The inflexible spec may lead vendor/OEM hard to follow.
Because the Machine mode timer I added in Linux2022 platform and System Peripherals section is removed from the patch, I will just leave the one in Embedded 2022 section untouched for further discussion.
Seems ACLINT is not designed to give the flexible offsets to mtime and mtimecmp to afford the adjacent register layout unless we introduce a new capability to MTIME device in ACLINT. We probably can work on making MTIME device register layout more flexible in ACLINT spec, I don't have the preference here...and I remember we would like to separate MTIME from CLINT spec, but now it goes into another spec :)

Regards,
Abner 

Alistair

>
> Regards,
> Anup
>
> >
> > Alistair
> >
> > > ----------------------------
> > > +
> > > https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RI
> > > SC-V
> > >  ACLINT Specification]
> > > +defines the memory map layout of Machine mode timer registers.
> > >
> > >  ==== Memory Map
> > >  It is recommended that main memory and loadable code (not ROM)
> > > start
> > > at
> >
> >
> >
> >
> >
>

Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Josh Scheid
 

Thanks for writing this up, Anup.

In https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc#24-synchronizing-multiple-mtimer-devices, the SW algorithm should include verifying the reference-target delta, retrying if the delta is out of bounds, and / or reporting failure to verify the synchronization is in bounds.

-Josh


On Tue, May 25, 2021 at 10:18 PM Anup Patel <anup.patel@...> wrote:
Hi All,

The RISC-V ACLINT specification is now hosted on RISC-V GitHub page:
https://github.com/riscv/riscv-aclint
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

Please review this at your end send feedback on AIA/Platform mailing
lists.

The RISC-V ACLINT specification is intended to be small and backward
compatible to the SiFive CLINT specification which makes existing
RISC-V platforms compliant with the RISC-V ACLINT specification.

Overall, from platforms specification perspective it complements
the RISC-V AIA specification by providing IPI and Timer functionality.

A complete functional implementation is available for QEMU RISC-V
along with OpenSBI and Linux RISC-V changes. Please refer, the
riscv_aclint_v1 branch in following repos:
https://github.com/avpatel/qemu.git
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git

To enable ACLINT emulation on QEMU, use "-M virt,aclint=on"
instead of just "-M virt" in your QEMU command line. For now,
QEMU supports ACLINT only for virt machine.

Regards,
Anup
Re: [RESEND PATCH v5 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Alistair Francis
 

On Wed, 2021-05-26 at 10:40 +0000, Anup Patel wrote:
Hi Alistair,

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

On Wed, 2021-05-26 at 12:57 +0800, renba.chang@... wrote:
From: Abner Chang <renba.chang@...>

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

On v5 commit,
- Remove CLINT from platform spec
- Require ACLINT on Linux2020 platform and have a link to
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc
.
- Remove Machine mode timer from previous patch because that is in
the
scope of ACLINT
- For Embedded-2022 platform, mention Machine mode timer and refer
to
ACLINT for the definition of registers

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 | 52 ++++++++++++++++++------------------
--
--
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index
160c74a..db6dce3 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,9 +49,23 @@ 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[R
ISC-V
 PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== ACLINT
+Linux-2020 platform requires the Advanced Core Local Interruptor
(ACLINT, refer
+to
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RI
SC-V
 ACLINT Specification])
+to provide facilities to route inter-processor interrupt and
Machine
mode timer
+interrupt to each RISC-V processor hart.
+
+===== Interrupt Assignments

 ==== System Peripherals
 * UART/Serial Console
@@ -289,9 +303,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[CL
IC]
+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[CL
IC]
 or both a CLIC and and PLIC.

 If using just a PLIC the system must continue to use the original
basic @@ -303,8 +316,8 @@ 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
+==== Machine Mode Timer
+The RISC-V Machine mode timer (controlled via `mtime` and
`mtimecmp`) must be
 implemented. The two registers must be memory mapped as required
by
the RISC-V
 specification.

@@ -314,27 +327,8 @@ 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 |
-===========================
You have removed the original  example, but not the original
description. If we
aren't supporting the adjancent addresses the paragraph above this
should be
removed.

I still prefer to allow either adjacent registers (as currently
described) OR the new ACLINT, but if everyone else thinks the ACLINT
is the
only way to go then that's fine.
The ACLINT MTIMER register organization is intentionally kept
compatible
with CLINT timer registers so that ACLINT is backward compatible.
Yep that's great for Linux systems. I haven't seen any embedded systems
besides SiFive that use the CLINT though.

For example SweRVolf uses a specific system controller:
https://github.com/chipsalliance/Cores-SweRVolf/#system-controller

and OpenTitan has it's own timer:
https://docs.opentitan.org/hw/ip/rv_timer/doc/

The ESP32 doesn't even include mtime so that's a different problem.


If you want a different register layout then this has to be defined
somewhere. The hardware cost of organizing registers like CLINT
is not much so it's difficult to justify why we want to organize
registers differently.
For devices that define their own timer I agree that arranging them
like the CLINT shouldn't be a problem. For ones that include the
mtime/mtimecmp in an other system controller I'm worried they will
instead just not try and meet the embedded spec.

We have already defined the layout here, so I don't think it requires
any more work. I agree 100% that it's more of a burden for software to
support two possible timer layouts, but if HW vendors don't opt to
follow the spec then we have to support a lot more.

Anyway, I'm not completely against only allowing ACLINT, I just wanted
to put it out there that it might be difficult for some vendors to
meet. We aren't requiring use of the PLIC or CLIC so it seems a little
strange to then mandate the ACLINT.

Alistair


Regards,
Anup


Alistair

----------------------------
+
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RI
SC-V
 ACLINT Specification]
+defines the memory map layout of Machine mode timer registers.

 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM)
start
at
Re: [RESEND PATCH v5 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Anup Patel
 

Hi Alistair,

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

On Wed, 2021-05-26 at 12:57 +0800, renba.chang@... wrote:
From: Abner Chang <renba.chang@...>

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

On v5 commit,
- Remove CLINT from platform spec
- Require ACLINT on Linux2020 platform and have a link to
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc.
- Remove Machine mode timer from previous patch because that is in the
scope of ACLINT
- For Embedded-2022 platform, mention Machine mode timer and refer to
ACLINT for the definition of registers

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 | 52 ++++++++++++++++++--------------------
--
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index
160c74a..db6dce3 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,9 +49,23 @@ 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[R
ISC-V
 PLIC Specification]
+for the implementation reference of PLIC operation parameters)
+
+===== ACLINT
+Linux-2020 platform requires the Advanced Core Local Interruptor
(ACLINT, refer
+to
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RI
SC-V
 ACLINT Specification])
+to provide facilities to route inter-processor interrupt and Machine
mode timer
+interrupt to each RISC-V processor hart.
+
+===== Interrupt Assignments

 ==== System Peripherals
 * UART/Serial Console
@@ -289,9 +303,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[CL
IC]
+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[CL
IC]
 or both a CLIC and and PLIC.

 If using just a PLIC the system must continue to use the original
basic @@ -303,8 +316,8 @@ 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
+==== Machine Mode Timer
+The RISC-V Machine mode timer (controlled via `mtime` and
`mtimecmp`) must be
 implemented. The two registers must be memory mapped as required by
the RISC-V
 specification.

@@ -314,27 +327,8 @@ 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 |
-===========================
You have removed the original example, but not the original description. If we
aren't supporting the adjancent addresses the paragraph above this should be
removed.

I still prefer to allow either adjacent registers (as currently
described) OR the new ACLINT, but if everyone else thinks the ACLINT is the
only way to go then that's fine.
The ACLINT MTIMER register organization is intentionally kept compatible
with CLINT timer registers so that ACLINT is backward compatible.

If you want a different register layout then this has to be defined
somewhere. The hardware cost of organizing registers like CLINT
is not much so it's difficult to justify why we want to organize
registers differently.

Regards,
Anup


Alistair

----------------------------
+
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RI
SC-V
 ACLINT Specification]
+defines the memory map layout of Machine mode timer registers.

 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM) start
at
Re: [RESEND PATCH v5 1/2] riscv-platform-spec: PLIC and CLINT for Linux-2022 platform

Alistair Francis
 

On Wed, 2021-05-26 at 12:57 +0800, renba.chang@... wrote:
From: Abner Chang <renba.chang@...>

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

On v5 commit,
- Remove CLINT from platform spec
- Require ACLINT on Linux2020 platform and have a link to
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc.
- Remove Machine mode timer from previous patch because that is in
the scope of ACLINT
- For Embedded-2022 platform, mention Machine mode timer and refer to
ACLINT for the definition of registers

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 | 52 ++++++++++++++++++--------------------
--
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..db6dce3 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,9 +49,23 @@ 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)
+
+===== ACLINT
+Linux-2020 platform requires the Advanced Core Local Interruptor
(ACLINT, refer
+to
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RISC-V
 ACLINT Specification])
+to provide facilities to route inter-processor interrupt and Machine
mode timer
+interrupt to each RISC-V processor hart.
+
+===== Interrupt Assignments
 
 ==== System Peripherals
 * UART/Serial Console
@@ -289,9 +303,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,8 +316,8 @@ 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
+==== Machine Mode Timer
+The RISC-V Machine mode timer (controlled via `mtime` and
`mtimecmp`) must be
 implemented. The two registers must be memory mapped as required by
the RISC-V
 specification.
 
@@ -314,27 +327,8 @@ 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 |
-===========================
You have removed the original example, but not the original
description. If we aren't supporting the adjancent addresses the
paragraph above this should be removed.

I still prefer to allow either adjacent registers (as currently
described) OR the new ACLINT, but if everyone else thinks the ACLINT is
the only way to go then that's fine.

Alistair

----------------------------
+
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc[RISC-V
 ACLINT Specification]
+defines the memory map layout of Machine mode timer registers.
 
 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM) start
at
RISC-V ACLINT specification is now hosted on RISC-V GitHub

Anup Patel
 

Hi All,

The RISC-V ACLINT specification is now hosted on RISC-V GitHub page:
https://github.com/riscv/riscv-aclint
https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc

Please review this at your end send feedback on AIA/Platform mailing
lists.

The RISC-V ACLINT specification is intended to be small and backward
compatible to the SiFive CLINT specification which makes existing
RISC-V platforms compliant with the RISC-V ACLINT specification.

Overall, from platforms specification perspective it complements
the RISC-V AIA specification by providing IPI and Timer functionality.

A complete functional implementation is available for QEMU RISC-V
along with OpenSBI and Linux RISC-V changes. Please refer, the
riscv_aclint_v1 branch in following repos:
https://github.com/avpatel/qemu.git
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git

To enable ACLINT emulation on QEMU, use "-M virt,aclint=on"
instead of just "-M virt" in your QEMU command line. For now,
QEMU supports ACLINT only for virt machine.

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

Abner Chang
 

Hi Alistar,
Please check if you are ok with v5 patch.
Thanks
Abner

Anup Patel <anup.patel@...> 於 2021年5月25日 週二 下午4:25寫道：

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@...> 於 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[]
> > >
>
>
>
>
>

[RESEND PATCH v5 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
861 - 880 of 1850