On Wed, 2021-05-26 at 10:40 +0000, Anup Patel wrote:
-----Original Message-----The ACLINT MTIMER register organization is intentionally kept
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]
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@...>You have removed the original example, but not the original
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
- Remove Machine mode timer from previous patch because that is in
scope of ACLINT
- For Embedded-2022 platform, mention Machine mode timer and refer
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
IPI because AIA already supported it.
- In Embedded-2022 Machine mode timer section, CLINT is not
- 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
Do you think this is a good place for Machine Mode Timer?
@Mayuresh, please check if you are ok with this change, not sure
overlaps with your text or not (The timer setion). I can remove
if you prefer to put this with your patch.
- In Embedded-2022, refer to Machine Mode Timer in System
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
184.108.40.206 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
@@ -49,9 +49,23 @@ include::profiles.adoc
* Start Address
==== Interrupt Controller
-* PLIC + CLINT
-* Interrupt Assignments
+The Platform Level Interrupt Controller (PLIC) provides facilities
+the non-local interrupts to the external interrupt of a hart
+with a given privilege mode in a given hart. The number of non-
+sources supported by PLIC and how does each of them connect to the
+context is PLIC core implementation-specific. +
+for the implementation reference of PLIC operation parameters)
+Linux-2020 platform requires the Advanced Core Local Interruptor
+to provide facilities to route inter-processor interrupt and
+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
meet the Embedded-2022
==== Interrupt Controller
-Embedded systems are recommended to use a spec compliant
-https://github.com/riscv/riscv-plic-spec[PLIC], a spec compliant
+Embedded systems are recommended to use a spec compliant
<<PLIC,PLIC>>, a spec
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
call it a PLIC or CLIC.
-==== Machine Timer
-The RISC-V machine timer (controlled via `mtime` and `mtimecmp`)
+==== 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
@@ -314,27 +327,8 @@ adjacent to each other with the `mtime` region
the lower address.
The starting address of this region can be located anywhere in
memory, including inside other peripherals, as long as the start
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 |
description. If we
aren't supporting the adjancent addresses the paragraph above this
I still prefer to allow either adjacent registers (as currently
described) OR the new ACLINT, but if everyone else thinks the ACLINT
only way to go then that's fine.
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
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.
+defines the memory map layout of Machine mode timer registers.
==== Memory Map
It is recommended that main memory and loadable code (not ROM)