[PATCH V3 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 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 | 88 +++++++++++++++++++++++-----------------
1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..91c2abb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,14 +49,56 @@ include::profiles.adoc[]
* Start Address

==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== 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
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and incorporate with
+CLINT for the local interrupt to hart. The format of the 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 below,
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x4004` ||mtimecmp high for hart 0
+|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x400c` ||mtimecmp high for hart 1
+|... ||
+|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0xbff4` ||mtimecmp high for hart 4094
+|=======
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0xbff8` |mtime|mtime low
+|`0xbffc` ||mtime high
+|=======
* Watchdog Timers

==== Boot Process
@@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt (<<CLINT, CLINT>>).

==== Memory Map
It is recommended that main memory and loadable code (not ROM) start at
--
2.19.0.windows.1


Greg Favor
 

I notice many uses of the word "recommend".  My understanding is that there should be no recommendations in the platform spec - just requirements.  (To be more precise, I believe the Platforms Policy doc puts non-normative content in separate chapters.)

Greg


On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.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 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 | 88 +++++++++++++++++++++++-----------------
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..91c2abb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,14 +49,56 @@ include::profiles.adoc[]
 * Start Address

 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== 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
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and incorporate with
+CLINT for the local interrupt to hart. The format of the 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 below,
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x4004` ||mtimecmp high for hart 0
+|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x400c` ||mtimecmp high for hart 1
+|... ||
+|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0xbff4` ||mtimecmp high for hart 4094
+|=======
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0xbff8` |mtime|mtime low
+|`0xbffc` ||mtime high
+|=======
 * Watchdog Timers

 ==== Boot Process
@@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt (<<CLINT, CLINT>>).

 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM) start at
--
2.19.0.windows.1







Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午12:25寫道:
I notice many uses of the word "recommend".  My understanding is that there should be no recommendations in the platform spec - just requirements.  (To be more precise, I believe the Platforms Policy doc puts non-normative content in separate chapters.)

Greg

Hi Greg,
There is no "recommend" in this patch, I think we can create an issue for this on Github.
Regards,
Abner


On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.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 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 | 88 +++++++++++++++++++++++-----------------
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..91c2abb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,14 +49,56 @@ include::profiles.adoc[]
 * Start Address

 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== 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
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and incorporate with
+CLINT for the local interrupt to hart. The format of the 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 below,
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x4004` ||mtimecmp high for hart 0
+|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x400c` ||mtimecmp high for hart 1
+|... ||
+|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0xbff4` ||mtimecmp high for hart 4094
+|=======
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0xbff8` |mtime|mtime low
+|`0xbffc` ||mtime high
+|=======
 * Watchdog Timers

 ==== Boot Process
@@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt (<<CLINT, CLINT>>).

 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM) start at
--
2.19.0.windows.1







Greg Favor
 

On Fri, May 7, 2021 at 9:43 AM Abner Chang <renba.chang@...> wrote:
Hi Greg,
There is no "recommend" in this patch, I think we can create an issue for this on Github.

I think (?) we are meaning the same thing:  There is new text that uses the word "recommend", and all such uses need to be removed and turned into more appropropriate text (e.g. requirements).  Which is what the GH issue will cover.  Here's one example of what I'm referring to:

+Embedded systems are recommended to use a spec compliant <<PLIC,PLIC>>, a spec

Greg


Greg Favor
 

On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.chang@...> wrote:
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?

I think we need a two-part treatment of the M-mode timer requirements.

For the "legacy/deprecated" PLIC+CLINT requirement, the platform spec should contain separate chapters that provide specs of the required PLIC and CLINT.  When this requirement gets removed in the 2024 platform spec, these chapters will simply disappear.

For the "new" AIA+"M-mode timer" requirement, the platform spec should contain a separate chapter that specs just the M-mode timer hardware.  This happens to be a subset of the above CLINT spec, but should be a standalone spec (especially since the CLINT chapter will eventually go away).

In the "M-mode timer" chapter, the offsets should be rebased to 0x0, i.e. the mtimecmp registers start at offset 0x0000, and mtime is at 0x7FF8.

Greg

 



Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午1:15寫道:
On Fri, May 7, 2021 at 9:43 AM Abner Chang <renba.chang@...> wrote:
Hi Greg,
There is no "recommend" in this patch, I think we can create an issue for this on Github.

I think (?) we are meaning the same thing:  There is new text that uses the word "recommend", and all such uses need to be removed and turned into more appropropriate text (e.g. requirements).  Which is what the GH issue will cover.  Here's one example of what I'm referring to:

+Embedded systems are recommended to use a spec compliant <<PLIC,PLIC>>, a spec

I can have a separate patch for cleaning up all of those "recommended".
Abner

Greg


Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午1:25寫道:
On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.chang@...> wrote:
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?

I think we need a two-part treatment of the M-mode timer requirements.

For the "legacy/deprecated" PLIC+CLINT requirement, the platform spec should contain separate chapters that provide specs of the required PLIC and CLINT.  When this requirement gets removed in the 2024 platform spec, these chapters will simply disappear.

For the "new" AIA+"M-mode timer" requirement, the platform spec should contain a separate chapter that specs just the M-mode timer hardware.  This happens to be a subset of the above CLINT spec, but should be a standalone spec (especially since the CLINT chapter will eventually go away).
This seems a better structure.  I will revise it.

In the "M-mode timer" chapter, the offsets should be rebased to 0x0, i.e. the mtimecmp registers start at offset 0x0000, and mtime is at 0x7FF8.
The Offset 0 is Software interrupt registers. Rebase those mtime registers to 0x0 is not compliant with SiFive spec and the opensbi CLINT implementation.

Thanks
Abner

Greg

 



Greg Favor
 

On Fri, May 7, 2021 at 7:15 PM Abner Chang <renba.chang@...> wrote:
In the "M-mode timer" chapter, the offsets should be rebased to 0x0, i.e. the mtimecmp registers start at offset 0x0000, and mtime is at 0x7FF8.
The Offset 0 is Software interrupt registers. Rebase those mtime registers to 0x0 is not compliant with SiFive spec and the opensbi CLINT implementation.

What I meant would be fully compatible with the SiFive spec.  The point is that when the "M-mode timer" spec has nothing in the first 16KiB of what is the CLINT memory map, one would specify the base address of the "M-mode timer" block of registers as the address of the first "M-mode timer" register.  One would not specify a base address for the "M-mode timer" registers to start four pages before the beginning of the block of "M-mode timer" registers.  No one normally ever would do that.

Put differently, when a CLINT is present, the base address would be for the beginning of the block of CLINT registers.  And when just  "M-mode timer" registers are present, the base address would be for the beginning of the block of "M-mode timer" registers.

Greg


Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午11:53寫道:
On Fri, May 7, 2021 at 7:15 PM Abner Chang <renba.chang@...> wrote:
In the "M-mode timer" chapter, the offsets should be rebased to 0x0, i.e. the mtimecmp registers start at offset 0x0000, and mtime is at 0x7FF8.
The Offset 0 is Software interrupt registers. Rebase those mtime registers to 0x0 is not compliant with SiFive spec and the opensbi CLINT implementation.

What I meant would be fully compatible with the SiFive spec.  The point is that when the "M-mode timer" spec has nothing in the first 16KiB of what is the CLINT memory map, one would specify the base address of the "M-mode timer" block of registers as the address of the first "M-mode timer" register.  One would not specify a base address for the "M-mode timer" registers to start four pages before the beginning of the block of "M-mode timer" registers.  No one normally ever would do that.

Put differently, when a CLINT is present, the base address would be for the beginning of the block of CLINT registers.  And when just  "M-mode timer" registers are present, the base address would be for the beginning of the block of "M-mode timer" registers.
When the CLINT exists, the base address points to a block in which the software interrupt registers is the first block(0x00), My concern is we may have to introduce CLINT_MTIME_OFFSET (e.g. 0x4000) to the current opensbi CLINT implementation as the base address of mtime registers, thus mtime register block could be based at 0x0.  Are we on the same page or I miss something?  
With the above, opensbi CLINT implementation is compliant with platform spec, or we don't care about the current implementation? 
BTW,  mtime should be at 0x3ff8 if mtimecmp is at offset 0x0.

Abner


Greg


Greg Favor
 

On Sat, May 8, 2021 at 1:09 AM Abner Chang <renba.chang@...> wrote:
Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午11:53寫道:
What I meant would be fully compatible with the SiFive spec.  The point is that when the "M-mode timer" spec has nothing in the first 16KiB of what is the CLINT memory map, one would specify the base address of the "M-mode timer" block of registers as the address of the first "M-mode timer" register.  One would not specify a base address for the "M-mode timer" registers to start four pages before the beginning of the block of "M-mode timer" registers.  No one normally ever would do that.

Put differently, when a CLINT is present, the base address would be for the beginning of the block of CLINT registers.  And when just  "M-mode timer" registers are present, the base address would be for the beginning of the block of "M-mode timer" registers.
When the CLINT exists, the base address points to a block in which the software interrupt registers is the first block(0x00), My concern is we may have to introduce CLINT_MTIME_OFFSET (e.g. 0x4000) to the current opensbi CLINT implementation as the base address of mtime registers, thus mtime register block could be based at 0x0.  Are we on the same page or I miss something?  

Cc'ing Anup and Atish who should be the ones to rule on how OpenSBI handles this issue.

The reasoning behind my suggestion below is that when CLINT disappears in the 2024 platform spec, there should not be permanent vestiges left lying around.  Someone three years from now shouldn't be wondering why the base address of the M-mode timer registers must be computed as something like (CLINT_BASE +  CLINT_MTIME_OFFSET) instead of, say, "MTIME_BASE" (especially when CLINT has no definition in that platform spec).

Since the two parts of CLINT are functionality separate and independent of each other, I suggest they have separate base addresses, e.g. "MSIP_BASE" and "MTIME_BASE".  When a CLINT is present, the latter will happen to be +0x4000 of the former.  In an AIA system the former goes away and one is cleanly left with just the latter.
 
BTW,  mtime should be at 0x3ff8 if mtimecmp is at offset 0x0.

I think my math was correct.  In a CLINT, mtime is at offset 0xBFF8.  Subtracting the offset 0x4000 (to the first mtimecmp register) results in 0x7FF8.

Greg


Greg Favor
 

To be more complete about the issue of CLINT going away in future OS-A platform specs, I should note that everything I said is correct wrt the "AIA including IMSIC and APLIC" requirement.  This may get modified if the APLIC gets enhanced in the near-term to support IPI's (thus allowing for APLIC-only AIA systems).  That still won't have any use for the MSIP part of a CLINT.

But if, instead, the end result is that IMSIC's aren't required and there is not an enhanced APLIC, then software won't be able to do S-mode IPIs, only M-mode IPI's will be available, and the MSIP part of CLINT will be needed.  This would be an ugly outcome that we will hopefully avoid.  But what I suggested in my last post would still support this outcome, i.e. an AIA system would then be required to either have IMSIC's or "MSIP" registers.

Greg

On Sat, May 8, 2021 at 12:57 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
On Sat, May 8, 2021 at 1:09 AM Abner Chang <renba.chang@...> wrote:
Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午11:53寫道:
What I meant would be fully compatible with the SiFive spec.  The point is that when the "M-mode timer" spec has nothing in the first 16KiB of what is the CLINT memory map, one would specify the base address of the "M-mode timer" block of registers as the address of the first "M-mode timer" register.  One would not specify a base address for the "M-mode timer" registers to start four pages before the beginning of the block of "M-mode timer" registers.  No one normally ever would do that.

Put differently, when a CLINT is present, the base address would be for the beginning of the block of CLINT registers.  And when just  "M-mode timer" registers are present, the base address would be for the beginning of the block of "M-mode timer" registers.
When the CLINT exists, the base address points to a block in which the software interrupt registers is the first block(0x00), My concern is we may have to introduce CLINT_MTIME_OFFSET (e.g. 0x4000) to the current opensbi CLINT implementation as the base address of mtime registers, thus mtime register block could be based at 0x0.  Are we on the same page or I miss something?  

Cc'ing Anup and Atish who should be the ones to rule on how OpenSBI handles this issue.

The reasoning behind my suggestion below is that when CLINT disappears in the 2024 platform spec, there should not be permanent vestiges left lying around.  Someone three years from now shouldn't be wondering why the base address of the M-mode timer registers must be computed as something like (CLINT_BASE +  CLINT_MTIME_OFFSET) instead of, say, "MTIME_BASE" (especially when CLINT has no definition in that platform spec).

Since the two parts of CLINT are functionality separate and independent of each other, I suggest they have separate base addresses, e.g. "MSIP_BASE" and "MTIME_BASE".  When a CLINT is present, the latter will happen to be +0x4000 of the former.  In an AIA system the former goes away and one is cleanly left with just the latter.
 
BTW,  mtime should be at 0x3ff8 if mtimecmp is at offset 0x0.

I think my math was correct.  In a CLINT, mtime is at offset 0xBFF8.  Subtracting the offset 0x4000 (to the first mtimecmp register) results in 0x7FF8.

Greg


Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月9日 週日 上午3:57寫道:
On Sat, May 8, 2021 at 1:09 AM Abner Chang <renba.chang@...> wrote:
Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午11:53寫道:
What I meant would be fully compatible with the SiFive spec.  The point is that when the "M-mode timer" spec has nothing in the first 16KiB of what is the CLINT memory map, one would specify the base address of the "M-mode timer" block of registers as the address of the first "M-mode timer" register.  One would not specify a base address for the "M-mode timer" registers to start four pages before the beginning of the block of "M-mode timer" registers.  No one normally ever would do that.

Put differently, when a CLINT is present, the base address would be for the beginning of the block of CLINT registers.  And when just  "M-mode timer" registers are present, the base address would be for the beginning of the block of "M-mode timer" registers.
When the CLINT exists, the base address points to a block in which the software interrupt registers is the first block(0x00), My concern is we may have to introduce CLINT_MTIME_OFFSET (e.g. 0x4000) to the current opensbi CLINT implementation as the base address of mtime registers, thus mtime register block could be based at 0x0.  Are we on the same page or I miss something?  

Cc'ing Anup and Atish who should be the ones to rule on how OpenSBI handles this issue.

The reasoning behind my suggestion below is that when CLINT disappears in the 2024 platform spec, there should not be permanent vestiges left lying around.  Someone three years from now shouldn't be wondering why the base address of the M-mode timer registers must be computed as something like (CLINT_BASE +  CLINT_MTIME_OFFSET) instead of, say, "MTIME_BASE" (especially when CLINT has no definition in that platform spec).
ok, just leave the implementation to opensbi people. I will revise mtimecmp to base at 0x0.

Since the two parts of CLINT are functionality separate and independent of each other, I suggest they have separate base addresses, e.g. "MSIP_BASE" and "MTIME_BASE".  When a CLINT is present, the latter will happen to be +0x4000 of the former.  In an AIA system the former goes away and one is cleanly left with just the latter.
 
BTW,  mtime should be at 0x3ff8 if mtimecmp is at offset 0x0.

I think my math was correct.  In a CLINT, mtime is at offset 0xBFF8.  Subtracting the offset 0x4000 (to the first mtimecmp register) results in 0x7FF8.
yes, I was wrong. don't know what's wrong with my mind at that moment. 
Abner

Greg


Alistair Francis
 

On Sat, 2021-05-08 at 00:01 +0800, renba.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 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 | 88 +++++++++++++++++++++++-----------------
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..91c2abb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,14 +49,56 @@ include::profiles.adoc[]
 * Start Address
 
 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== 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
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and incorporate
with
+CLINT for the local interrupt to hart. The format of the 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 below,
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x4004` ||mtimecmp high for hart 0
+|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x400c` ||mtimecmp high for hart 1
+|... ||
+|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0xbff4` ||mtimecmp high for hart 4094
+|=======
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for RV32*
+|`0xbff8` |mtime|mtime low
+|`0xbffc` ||mtime high
+|=======
 * Watchdog Timers
 
 ==== Boot Process
@@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt
(<<CLINT, CLINT>>).
We shouldn't be requiring a CLINT for embedded systems. That is too
strenuous of a requirement.

Instead I think we should leave the embedded section as is as it maps
the register layout in memory. This allows it to be included in system
controllers if hardware vendors want to.

Alistair

 
 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM) start
at


Alistair Francis
 

On Fri, 2021-05-07 at 09:25 -0700, Greg Favor wrote:
I notice many uses of the word "recommend".  My understanding is that
there should be no recommendations in the platform spec - just
requirements.  (To be more precise, I believe the Platforms Policy
doc puts non-normative content in separate chapters.)
Why are we removing recommendations?

For the embedded spec we don't want to force vendors to meet certain
requirements if they have a good reason not to. For example if they
share IP or memory maps across different product lines we want to allow
that. As that will make it easier for them and their customers to
transition to RISC-V.

On the other hand if vendors are picking addresses or IP we want to
encourage them to use a standard. Hence the recommendations.

Alistair


Greg


On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.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 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 | 88 +++++++++++++++++++++++-------------
--
--
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..91c2abb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,14 +49,56 @@ include::profiles.adoc[]
 * Start Address

 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== 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
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and
incorporate with
+CLINT for the local interrupt to hart. The format of the 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 below,
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x4004` ||mtimecmp high for hart 0
+|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x400c` ||mtimecmp high for hart 1
+|... ||
+|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0xbff4` ||mtimecmp high for hart 4094
+|=======
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
RV32*
+|`0xbff8` |mtime|mtime low
+|`0xbffc` ||mtime high
+|=======
 * Watchdog Timers

 ==== Boot Process
@@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt
(<<CLINT, CLINT>>).

 ==== Memory Map
 It is recommended that main memory and loadable code (not ROM)
start
at


Kumar Sankaran
 

On Sun, May 9, 2021 at 5:45 PM Alistair Francis <alistair.francis@...> wrote:
On Fri, 2021-05-07 at 09:25 -0700, Greg Favor wrote:
> I notice many uses of the word "recommend".  My understanding is that
> there should be no recommendations in the platform spec - just
> requirements.  (To be more precise, I believe the Platforms Policy
> doc puts non-normative content in separate chapters.)

Why are we removing recommendations?

For the embedded spec we don't want to force vendors to meet certain
requirements if they have a good reason not to. For example if they
share IP or memory maps across different product lines we want to allow
that. As that will make it easier for them and their customers to
transition to RISC-V.

On the other hand if vendors are picking addresses or IP we want to
encourage them to use a standard. Hence the recommendations.

Alistair

The goal is to have a minimal set of requirements that define a platform as part of the platform spec. Hence, only required features will be explicitly stated in the spec. If we allow the flexibility of "optional" or "recommended" features, platform vendors will end up not implementing them while claiming compatibility, while at the same time fewer others will implement them; overall fragmenting the eco-system.
So we should strive to make all recommendations as "Required" to the extent possible while removing all other non-required features out of the spec.
 
>
> Greg
>
>
> On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.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 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 | 88 +++++++++++++++++++++++-------------
> > --
> > --
> >  1 file changed, 50 insertions(+), 38 deletions(-)
> >
> > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > index 160c74a..91c2abb 100644
> > --- a/riscv-platform-spec.adoc
> > +++ b/riscv-platform-spec.adoc
> > @@ -49,14 +49,56 @@ include::profiles.adoc[]
> >  * Start Address
> >
> >  ==== Interrupt Controller
> > -* AIA
> > -* PLIC + CLINT
> > -* Interrupt Assignments
> > +===== 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
> > +
> > +===== Machine Mode Timer[[MachineModeTimer]]
> > +Machine mode timer is required for Linux-2022 platform and
> > incorporate with
> > +CLINT for the local interrupt to hart. The format of the 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 below,
> > +
> > +.Registers layout of mtimecmp
> > +[width="60%",cols="1,^3,^3"]
> > +|=======
> > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > +|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > +|`0x4004` ||mtimecmp high for hart 0
> > +|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > +|`0x400c` ||mtimecmp high for hart 1
> > +|... ||
> > +|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > +|`0xbff4` ||mtimecmp high for hart 4094
> > +|=======
> > +
> > +.Registers layout of mtime
> > +[width="60%",cols="1,^3,^3"]
> > +|=======
> > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > +|`0xbff8` |mtime|mtime low
> > +|`0xbffc` ||mtime high
> > +|=======
> >  * Watchdog Timers
> >
> >  ==== Boot Process
> > @@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt
> > (<<CLINT, CLINT>>).
> >
> >  ==== Memory Map
> >  It is recommended that main memory and loadable code (not ROM)
> > start
> > at








--
Regards
Kumar


Jonathan Behrens <behrensj@...>
 

I'd expect there could also be a category of "not required by this version of the platform spec, but will be required in the next one".

On Sun, May 9, 2021 at 9:33 PM Kumar Sankaran via lists.riscv.org <ksankaran=ventanamicro.com@...> wrote:
On Sun, May 9, 2021 at 5:45 PM Alistair Francis <alistair.francis@...> wrote:
On Fri, 2021-05-07 at 09:25 -0700, Greg Favor wrote:
> I notice many uses of the word "recommend".  My understanding is that
> there should be no recommendations in the platform spec - just
> requirements.  (To be more precise, I believe the Platforms Policy
> doc puts non-normative content in separate chapters.)

Why are we removing recommendations?

For the embedded spec we don't want to force vendors to meet certain
requirements if they have a good reason not to. For example if they
share IP or memory maps across different product lines we want to allow
that. As that will make it easier for them and their customers to
transition to RISC-V.

On the other hand if vendors are picking addresses or IP we want to
encourage them to use a standard. Hence the recommendations.

Alistair

The goal is to have a minimal set of requirements that define a platform as part of the platform spec. Hence, only required features will be explicitly stated in the spec. If we allow the flexibility of "optional" or "recommended" features, platform vendors will end up not implementing them while claiming compatibility, while at the same time fewer others will implement them; overall fragmenting the eco-system.
So we should strive to make all recommendations as "Required" to the extent possible while removing all other non-required features out of the spec.
 
>
> Greg
>
>
> On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.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 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 | 88 +++++++++++++++++++++++-------------
> > --
> > --
> >  1 file changed, 50 insertions(+), 38 deletions(-)
> >
> > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > index 160c74a..91c2abb 100644
> > --- a/riscv-platform-spec.adoc
> > +++ b/riscv-platform-spec.adoc
> > @@ -49,14 +49,56 @@ include::profiles.adoc[]
> >  * Start Address
> >
> >  ==== Interrupt Controller
> > -* AIA
> > -* PLIC + CLINT
> > -* Interrupt Assignments
> > +===== 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
> > +
> > +===== Machine Mode Timer[[MachineModeTimer]]
> > +Machine mode timer is required for Linux-2022 platform and
> > incorporate with
> > +CLINT for the local interrupt to hart. The format of the 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 below,
> > +
> > +.Registers layout of mtimecmp
> > +[width="60%",cols="1,^3,^3"]
> > +|=======
> > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > +|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
> > +|`0x4004` ||mtimecmp high for hart 0
> > +|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
> > +|`0x400c` ||mtimecmp high for hart 1
> > +|... ||
> > +|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
> > +|`0xbff4` ||mtimecmp high for hart 4094
> > +|=======
> > +
> > +.Registers layout of mtime
> > +[width="60%",cols="1,^3,^3"]
> > +|=======
> > +|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte) for
> > RV32*
> > +|`0xbff8` |mtime|mtime low
> > +|`0xbffc` ||mtime high
> > +|=======
> >  * Watchdog Timers
> >
> >  ==== Boot Process
> > @@ -289,9 +331,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 +344,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 and incorporated with the Core Local Interrupt
> > (<<CLINT, CLINT>>).
> >
> >  ==== Memory Map
> >  It is recommended that main memory and loadable code (not ROM)
> > start
> > at








--
Regards
Kumar


Alistair Francis
 

On Sun, 2021-05-09 at 22:23 -0400, Jonathan Behrens wrote:
I'd expect there could also be a category of "not required by this
version of the platform spec, but will be required in the next one".
But we don't want it required in the next one either.

The idea is to allow vendors to be flexible and share IP between their
current ISA offering and thir RISC-V chips. Look at the latest
Espressif RISC-V MCU for example. While also encouraging new products
to follow a common RISC-V layout if possible.

Alistair


On Sun, May 9, 2021 at 9:33 PM Kumar Sankaran via lists.riscv.org <
ksankaran=ventanamicro.com@...> wrote:
On Sun, May 9, 2021 at 5:45 PM Alistair Francis <
alistair.francis@...> wrote:
On Fri, 2021-05-07 at 09:25 -0700, Greg Favor wrote:
I notice many uses of the word "recommend".  My understanding
is
that
there should be no recommendations in the platform spec - just
requirements.  (To be more precise, I believe the Platforms
Policy
doc puts non-normative content in separate chapters.)
Why are we removing recommendations?

For the embedded spec we don't want to force vendors to meet
certain
requirements if they have a good reason not to. For example if
they
share IP or memory maps across different product lines we want to
allow
that. As that will make it easier for them and their customers to
transition to RISC-V.

On the other hand if vendors are picking addresses or IP we want
to
encourage them to use a standard. Hence the recommendations.

Alistair

The goal is to have a minimal set of requirements that define a
platform as part of the platform spec. Hence, only required
features will be explicitly stated in the spec. If we allow the
flexibility of "optional" or "recommended" features,
platform vendors will end up not implementing them while claiming
compatibility, while at the same time fewer others will implement
them; overall fragmenting the eco-system.
So we should strive to make all recommendations as "Required" to
the extent possible while removing all other non-required features
out of the spec.
 

Greg


On Fri, May 7, 2021 at 9:01 AM Abner Chang
<renba.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 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 | 88 +++++++++++++++++++++++-------
--
----
--
--
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-
spec.adoc
index 160c74a..91c2abb 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -49,14 +49,56 @@ include::profiles.adoc[]
 * Start Address

 ==== Interrupt Controller
-* AIA
-* PLIC + CLINT
-* Interrupt Assignments
+===== 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
+
+===== Machine Mode Timer[[MachineModeTimer]]
+Machine mode timer is required for Linux-2022 platform and
incorporate with
+CLINT for the local interrupt to hart. The format of the
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 below,
+
+.Registers layout of mtimecmp
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte)
for
RV32*
+|`0x4000` |mtimecmp for hart 0 |mtimecmp low for hart 0
+|`0x4004` ||mtimecmp high for hart 0
+|`0x4008` |mtimecmp for hart 1 |mtimecmp low for hart 1
+|`0x400c` ||mtimecmp high for hart 1
+|... ||
+|`0xbff0` |mtimecmp for hart 4094|mtimecmp low for hart 4094
+|`0xbff4` ||mtimecmp high for hart 4094
+|=======
+
+.Registers layout of mtime
+[width="60%",cols="1,^3,^3"]
+|=======
+|*Offset*|*Register (8-byte) for RV64*|*Register (4-byte)
for
RV32*
+|`0xbff8` |mtime|mtime low
+|`0xbffc` ||mtime high
+|=======
 * Watchdog Timers

 ==== Boot Process
@@ -289,9 +331,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 +344,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 and incorporated with the Core Local
Interrupt
(<<CLINT, CLINT>>).

 ==== Memory Map
 It is recommended that main memory and loadable code (not
ROM)
start
at





Abner Chang
 



Greg Favor <gfavor@...> 於 2021年5月8日 週六 上午1:25寫道:
On Fri, May 7, 2021 at 9:01 AM Abner Chang <renba.chang@...> wrote:
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?

I think we need a two-part treatment of the M-mode timer requirements.

For the "legacy/deprecated" PLIC+CLINT requirement, the platform spec should contain separate chapters that provide specs of the required PLIC and CLINT.  When this requirement gets removed in the 2024 platform spec, these chapters will simply disappear.

For the "new" AIA+"M-mode timer" requirement, the platform spec should contain a separate chapter that specs just the M-mode timer hardware.  This happens to be a subset of the above CLINT spec, but should be a standalone spec (especially since the CLINT chapter will eventually go away).
 
Hi Greg,
I am going to restructure the sections for PLIC/CLINT/MTIMER. I am not quite sure your preference of  "separate chapters that provide specs of the required PLIC and CLINT". The chapters in riscv-platform-spec are based on the platform definition, thus I think to have separate sections is good enough. The structure of sections would be looked as below,

1.1.3. Interrupt Controller
1.1.3.1  AIA
1.1.3.2  PLIC + CLINT [DEPRECATED]
1.1.3.3. Interrupt Assignments

1.1.4. System Peripherals
1.1.4.1 UART/Serial Console
1.1.4.2. Clocks
1.1.4.3. Timers
1.1.4.4. ,Watchdog Timers
1.1.4.5. Machine Mode Timer
 
With the above, we can remove 1.1.3.2 section for Linux2024. Is this ok?

Regards,
Abner


In the "M-mode timer" chapter, the offsets should be rebased to 0x0, i.e. the mtimecmp registers start at offset 0x0000, and mtime is at 0x7FF8.

Greg

 



Greg Favor
 

On Mon, May 17, 2021 at 8:24 AM Abner Chang <renba.chang@...> wrote:
Hi Greg,
I am going to restructure the sections for PLIC/CLINT/MTIMER. I am not quite sure your preference of  "separate chapters that provide specs of the required PLIC and CLINT". The chapters in riscv-platform-spec are based on the platform definition, thus I think to have separate sections is good enough. The structure of sections would be looked as below,

What I was trying to separate out from the main part of the platform spec (which is about specifying requirements), is the detailed register-level definitions of certain hardware components (like the things you listed below).  The detailed low-level definitions of each of these components should be located either in separate appendix chapters or in separate sections of an appendix chapter like what SBSA does (either way is fine with me; and if you want to instead treat them as normal chapters/sections and not call them appendices, that is fine as well).  

The central point is that the main chapters/sections of the platform specs should call out the requirements for various components and then just reference the related "appendix" chapters/sections for the detailed register-level definition of the components.

Greg
 

1.1.3. Interrupt Controller
1.1.3.1  AIA
1.1.3.2  PLIC + CLINT [DEPRECATED]
1.1.3.3. Interrupt Assignments

1.1.4. System Peripherals
1.1.4.1 UART/Serial Console
1.1.4.2. Clocks
1.1.4.3. Timers
1.1.4.4. ,Watchdog Timers
1.1.4.5. Machine Mode Timer
 
With the above, we can remove 1.1.3.2 section for Linux2024. Is this ok?

Regards,
Abner


In the "M-mode timer" chapter, the offsets should be rebased to 0x0, i.e. the mtimecmp registers start at offset 0x0000, and mtime is at 0x7FF8.

Greg