Date   

[PATCH v7] Add performance monitoring unit extension

Anup Patel
 

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

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

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

=== Version 0.2

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

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

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

No management.
--
2.25.1


Re: [PATCH v5 0/2] System Peripherals

Mayuresh Chitale
 

Atish, Johnathan,

Please let me know if any further changes are required.

Thanks,
Mayuresh.


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

Changes in V5:
  - Rebased on main

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

Changes in V3:

Base spec:
  - Clarified minimum requirement for counter resolution.

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

Changes in V2:

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

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

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

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

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

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

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

--
2.17.1







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

Mayuresh Chitale
 

Base spec:
- UART
- Clock and Timers

Server extension:
- Clock and Timers

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

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

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

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

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

==== Secure Boot
--
2.17.1


[PATCH v5 1/2] Updating contributors

Mayuresh Chitale
 

Adding myself to list of contributors.

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index 08b16f0..91cc46e 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -27,7 +27,8 @@ Andrew Waterman,
Kumar Sankaran,
Alistair Francis,
Sunil V L,
-Rahul Pathak
+Rahul Pathak,
+Mayuresh Chitale

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.17.1


[PATCH v5 0/2] System Peripherals

Mayuresh Chitale
 

This patch describes requirements for the system peripherals
like UART, clock and timers for the Linux-2022 platform
base spec and the server extension.

Changes in V5:
- Rebased on main

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

Changes in V3:

Base spec:
- Clarified minimum requirement for counter resolution.

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

Changes in V2:

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

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

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

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

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

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

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

--
2.17.1


Re: [PATCH v6] Add performance monitoring unit extension

atishp@...
 

On Fri, 2021-05-14 at 13:07 +0530, Anup Patel wrote:
This patch adds SBI performance monitoring unit (PMU) extension which
allows S-mode (or VS-mode) software to configure hardware (or
firmware)
performance counters with help of M-mode (or HS-mode) software.

Signed-off-by: Anup Patel <anup.patel@...>
Signed-off-by: Atish Patra <atish.patra@...>
---
Changes since v5:
- Improved NOTEs on SBI_PMU_HW_CPU_CYCLES, SBI_PMU_HW_REF_CPU_CYCLES,
  and SBI_PMU_HW_BUS_CYCLES events as suggested by Greg Favor
- Re-ordered paramters of sbi_pmu_counter_config_matching() so that
  uint64_t parameter is last one
- Added NOTEs for config_flags[3:7] bits which will be used for event
  filtering based on privilege mode
- Allow sbi_pmu_counter_start() and sbi_pmu_counter_stop() to work on
  a set of counters
- Re-ordered function numbering to make sbi_pmu_counter_fw_read() as
  last function
All the above changes looks good. I have verified those in the
OpenSBI/Linux kernel implementation as well. I will send out the
patches soon.


Changes since v4:
- Simplified "NOTE" section for RAW events
- Resized tables
- Added "SBI version" column to function list table
- Added "NOTE" section for SBI_PMU_HW_BUS_CYCLES and
SBI_PMU_HW_REF_CPU_CYCLE
- Explicity mention that event_data is 64 bits wide
- Only lower 56 bits of event_data are used for RAW events to align
with
  upcoming Sscof extension
Changes since v3:
- The new "sscof" extension requires the event info to be 64 bit.
- Improves:
  1. the counter start/stop function ids with a appropriate error
codes
  2. An additional flag parameter to accomodate "sscof extension".
- Renames:
  a. software counter to firmware counter to avoid ambiguity with
     kernel software events.
  b. event_info to event_data to avoid ambiguity with counter info
Changes since v2:
 - Rebased on makefile and cleanup changes
---
 riscv-sbi.adoc | 446
+++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 446 insertions(+)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index 16b7380..95dcc00 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -34,6 +34,7 @@ https://creativecommons.org/licenses/by/4.0/.
 * Improved SBI introduction secion
 * Improved documentation of SBI hart state managment extension
 * Added suspend function to SBI hart state managment extension
+* Added performance monitoring unit extension
 
 === Version 0.2
 
@@ -114,6 +115,8 @@ error codes.
 |  SBI_ERR_DENIED            | -4
 |  SBI_ERR_INVALID_ADDRESS   | -5
 |  SBI_ERR_ALREADY_AVAILABLE | -6
+|  SBI_ERR_ALREADY_STARTED   | -7
+|  SBI_ERR_ALREADY_STOPPED   | -8
 |===
 
 An `ECALL` with an unsupported SBI extension ID (*EID*) or an
unsupported SBI
@@ -1092,6 +1095,449 @@ The possible error codes returned in
`sbiret.error` are shown in the
 | sbi_system_reset    | 0.3         |   0 | 0x53525354
 |===
 
+== Performance Monitoring Unit Extension (EID #0x504D55 "PMU")
+
+The RISC-V hardware performance counters such as `mcycle`,
`minstret`, and
+`mhpmcounterX` CSRs are accessible as read-only from supervisor-mode
using
+`cycle`, `instret`, and `hpmcounterX` CSRs. The SBI performance
monitoring
+unit (PMU) extension is an interface for supervisor-mode to
configure and
+use the RISC-V hardware performance counters with assistance from
the
+machine-mode (or hypervisor-mode). These hardware performance
counters
+can only be started, stopped, or configured from machine-mode using
+`mcountinhibit` and `mhpmeventX` CSRs. Due to this, a machine-mode
SBI
+implementation may choose to disallow SBI PMU extension if
`mcountinhibit`
+CSR is not implemented by the RISC-V platform.
+
+A RISC-V platform generally supports monitoring of various hardware
events
+using a limited number of hardware performance counters which are up
to
+64 bits wide. In addition, a SBI implementation can also provide
firmware
+performance counters which can monitor firmware events such as
number of
+misaligned load/store instructions, number of RFENCEs, number of
IPIs, etc.
+The firmware counters are always 64 bits wide.
+
+The SBI PMU extension provides:
+
+1. An interface for supervisor-mode software to discover and
configure
+   per-HART hardware/firmware counters
+2. A typical
https://en.wikipedia.org/wiki/Perf_(Linux)[perf] compatible
+   interface for hardware/firmware performance counters and events
+3. Full access to microarchitecture's raw event encodings
+
+To define SBI PMU extension calls, we first define important
entities
+`counter_idx`, `event_idx`, and `event_data`. The `counter_idx` is a
+logical number assigned to each hardware/firmware counter. The
`event_idx`
+represents a hardware (or firmware) event whereas the `event_data`
is
+64 bits wide and represents additional configuration (or parameters)
for
+a hardware (or firmware) event.
+
+The event_idx is a 20 bits wide number encoded as follows:
+[source, C]
+----
+    event_idx[19:16] = type
+    event_idx[15:0] = code
+----
+
+=== Event: Hardware general events (Type #0)
+
+The `event_idx.type` (i.e. *event type*) should be `0x0` for all
hardware
+general events and each hardware general event is identified by an
unique
+`event_idx.code` (i.e. *event code*) described in the
+<<table_pmu_hardware_events>> below.
+
+[#table_pmu_hardware_events]
+.PMU Hardware Events
+[cols="6,1,4", width=95%, align="center", options="header"]
+|===
+| General Event Name                 | Code | Description
+| SBI_PMU_HW_NO_EVENT                |    0 | Unused event because
+                                              `event_idx` cannot be
zero
+| SBI_PMU_HW_CPU_CYCLES              |    1 | Event for each CPU
cycle
+| SBI_PMU_HW_INSTRUCTIONS            |    2 | Event for each
completed
+                                              instruction
+| SBI_PMU_HW_CACHE_REFERENCES        |    3 | Event for cache hit
+| SBI_PMU_HW_CACHE_MISSES            |    4 | Event for cache miss
+| SBI_PMU_HW_BRANCH_INSTRUCTIONS     |    5 | Event for a branch
instruction
+| SBI_PMU_HW_BRANCH_MISSES           |    6 | Event for a branch
misprediction
+| SBI_PMU_HW_BUS_CYCLES              |    7 | Event for each BUS
cycle
+| SBI_PMU_HW_STALLED_CYCLES_FRONTEND |    8 | Event for a stalled
cycle in
+                                              microarchitecture
frontend
+| SBI_PMU_HW_STALLED_CYCLES_BACKEND  |    9 | Event for a stalled
cycle in
+                                              microarchitecture
backend
+| SBI_PMU_HW_REF_CPU_CYCLES          |   10 | Event for each
reference
+                                              CPU cycle
+|===
+
+*NOTE:* The `event_data` (i.e. *event data*) is unused for hardware
+general events and all non-zero values of `event_data` are reserved
+for future use.
+
+*NOTE:* The *SBI_PMU_HW_CPU_CYCLES* event counts CPU clock cycles as
+counted by the `cycle` CSR. These may be variable frequency cycles,
and
+are not counted when the CPU clock is halted (i.e. WAIT state
entered
+using WFI instruction or platform specific SUSPEND state entered
using
+the SBI HSM HART suspend call).
+
+*NOTE:* The *SBI_PMU_HW_REF_CPU_CYCLES* counts fixed-frequency clock
+cycles while the CPU clock is not halted (i.e. WAIT state entered
using
+WFI instruction or platform specific SUSPEND state entered SBI HSM
HART
+suspend call). The fixed-frequency of counting might, for example,
be
+the same frequency at which the `mtime` CSR counts.
+
+*NOTE:* The *SBI_PMU_HW_BUS_CYCLES* counts fixed-frequency clock
cycles.
+The fixed-frequency of counting might be the same frequency at which
the
+`mtime` CSR counts, or may be the frequency of the clock at the
boundary
+between the HART (and it's private caches) and the rest of the
system.
+
+=== Event: Hardware cache events (Type #1)
+
+The `event_idx.type` (i.e. *event type*) should be `0x1` for all
hardware
+cache events and each hardware cache event is identified by an
unique
+`event_idx.code` (i.e. *event code*) which is encoded as follows:
+
+[source, C]
+----
+    event_idx.code[15:3] = cache_id
+    event_idx.code[2:1] = op_id
+    event_idx.code[0:0] = result_id
+----
+
+Below tables show possible values of: `event_idx.code.cache_id`
(i.e.
+*cache event id*), `event_idx.code.op_id` (i.e. *cache operation
id*)
+and `event_idx.code.result_id` (i.e. *cache result id*).
+
+[#table_pmu_cache_event_id]
+.PMU Cache Event ID
+[cols="6,2,4", width=95%, align="center", options="header"]
+|===
+| Cache Event Name      | Event ID | Description
+| SBI_PMU_HW_CACHE_L1D  |        0 | Level1 data cache event
+| SBI_PMU_HW_CACHE_L1I  |        1 | Level1 instruction cache event
+| SBI_PMU_HW_CACHE_LL   |        2 | Last level cache event
+| SBI_PMU_HW_CACHE_DTLB |        3 | Data TLB event
+| SBI_PMU_HW_CACHE_ITLB |        4 | Instruction TLB event
+| SBI_PMU_HW_CACHE_BPU  |        5 | Branch predictor unit event
+| SBI_PMU_HW_CACHE_NODE |        6 | NUMA node cache event
+|===
+
+[#table_pmu_cache_ops_id]
+.PMU Cache Operation ID
+[cols="6,2,4", width=95%, align="center", options="header"]
+|===
+| Cache Operation Name         | Operation ID | Description
+| SBI_PMU_HW_CACHE_OP_READ     |            0 | Read cache line
+| SBI_PMU_HW_CACHE_OP_WRITE    |            1 | Write cache line
+| SBI_PMU_HW_CACHE_OP_PREFETCH |            2 | Prefetch cache line
+|===
+
+[#table_pmu_cache_result_id]
+.PMU Cache Operation Result ID
+[cols="6,2,4", width=95%, align="center", options="header"]
+|===
+| Cache Result Name              | Result ID | Description
+| SBI_PMU_HW_CACHE_RESULT_ACCESS |         0 | Cache access
+| SBI_PMU_HW_CACHE_RESULT_MISS   |         1 | Cache miss
+|===
+
+*NOTE:* The `event_data` (i.e. *event data*) is unused for hardware
cache
+events and all non-zero values of `event_data` are reserved for
future use.
+
+=== Event: Hardware raw events (Type #2)
+
+The `event_idx.type` (i.e. *event type*) should be `0x2` for all
hardware
+raw events and `event_idx.code` (i.e. *event code*) should be zero.
The
+`event_data` configuration (or parameter) should have the 56 bits
wide
+non-zero event value to be programmed in the `mhpmeventX` CSR. The
upper
+8 bits of `event_data` are unused and all non-zero values of these
bits
+are reserved for future use.
+
+*Note:* Platform may choose to define the expected value to be
written to
+`mhpmeventX` CSR for a hardware event. In case of a hardware
general/cache
+events, platform may use the zero-extended `event_idx` as the
expected
+value for simplicity.
+
+=== Event: Firmware events (Type #15)
+
+The `event_idx.type` (i.e. *event type*) should be `0xf` for all
firmware
+events and each firmware event is identified by an unqiue
`event_idx.code`
+(i.e. *event code*) described in the <<table_pmu_firmware_events>>
below.
+
+[#table_pmu_firmware_events]
+.PMU Firmware Events
+[cols="6,1,4", width=95%, align="center", options="header"]
+|===
+| Firmware Event Name                  | Code | Description
+| SBI_PMU_FW_MISALIGNED_LOAD           |    0 | Misaligned load trap
event
+| SBI_PMU_FW_MISALIGNED_STORE          |    1 | Misaligned store
trap event
+| SBI_PMU_FW_ACCESS_LOAD               |    2 | Load access trap
event
+| SBI_PMU_FW_ACCESS_STORE              |    3 | Store access trap
event
+| SBI_PMU_FW_ILLEGAL_INSN              |    4 | Illegal instruction
trap event
+| SBI_PMU_FW_SET_TIMER                 |    5 | Set timer event
+| SBI_PMU_FW_IPI_SENT                  |    6 | Sent IPI to other
HART event
+| SBI_PMU_FW_IPI_RECEIVED              |    7 | Received IPI from
other
+                                                HART event
+| SBI_PMU_FW_FENCE_I_SENT              |    8 | Sent FENCE.I request
to
+                                                other HART event
+| SBI_PMU_FW_FENCE_I_RECEIVED          |    9 | Received FENCE.I
request
+                                                from other HART
event
+| SBI_PMU_FW_SFENCE_VMA_SENT           |   10 | Sent SFENCE.VMA
request
+                                                to other HART event
+| SBI_PMU_FW_SFENCE_VMA_RECEIVED       |   11 | Received SFENCE.VMA
request
+                                                from other HART
event
+| SBI_PMU_FW_SFENCE_VMA_ASID_SENT      |   12 | Sent SFENCE.VMA with
ASID
+                                                request to other
HART event
+| SBI_PMU_FW_SFENCE_VMA_ASID_RECEIVED  |   13 | Received SFENCE.VMA
with ASID
+                                                request from other
HART event
+| SBI_PMU_FW_HFENCE_GVMA_SENT          |   14 | Sent HFENCE.GVMA
request to
+                                                other HART event
+| SBI_PMU_FW_HFENCE_GVMA_RECEIVED      |   15 | Received HFENCE.GVMA
request
+                                                from other HART
event
+| SBI_PMU_FW_HFENCE_GVMA_VMID_SENT     |   16 | Sent HFENCE.GVMA
with VMID
+                                                request to other
HART event
+| SBI_PMU_FW_HFENCE_GVMA_VMID_RECEIVED |   17 | Received HFENCE.GVMA
with VMID
+                                                request from other
HART event
+| SBI_PMU_FW_HFENCE_VVMA_SENT          |   18 | Sent HFENCE.VVMA
request to
+                                                other HART event
+| SBI_PMU_FW_HFENCE_VVMA_RECEIVED      |   19 | Received HFENCE.VVMA
request
+                                                from other HART
event
+| SBI_PMU_FW_HFENCE_VVMA_ASID_SENT     |   20 | Sent HFENCE.VVMA
with ASID
+                                                request to other
HART event
+| SBI_PMU_FW_HFENCE_VVMA_ASID_RECEIVED |   21 | Received HFENCE.VVMA
with ASID
+                                                request from other
HART event
+|===
+
+*NOTE:* the `event_data` (i.e. *event data*) is unused for firmware
events
+and all non-zero values of `event_data` are reserved for future use.
+
+=== Function: Get number of counters (FID #0)
+
+[source, C]
+----
+struct sbiret sbi_pmu_num_counters()
+----
+
+*Returns* the number of counters (both hardware and firmware) in
+`sbiret.value` and always returns `SBI_SUCCESS` in sbiret.error.
+
+=== Function: Get details of a counter (FID #1)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_get_info(unsigned long counter_idx)
+----
+
+Get details about the specified counter such as underlying CSR
number,
+width of the counter, type of counter hardware/firmware, etc.
+
+The `counter_info` returned by this SBI call is encoded as follows:
+[source, C]
+----
+    counter_info[11:0] = CSR (12bit CSR number)
+    counter_info[17:12] = Width (One less than number of bits in
CSR)
+    counter_info[XLEN-2:18] = Reserved for future use
+    counter_info[XLEN-1] = Type (0 = hardware and 1 = firmware)
+----
+
+If `counter_info.type == 1` then `counter_info.csr` and
`counter_info.width`
+should be ignored.
+
+*Returns* the `counter_info` described above in `sbiret.value`.
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_get_info_errors>> below.
+
+[#table_pmu_counter_get_info_errors]
+.PMU Counter Get Info Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code            | Description
+| SBI_SUCCESS           | `counter_info` read successfully.
+| SBI_ERR_INVALID_PARAM | `counter_idx` points to an invalid
counter.
+|===
+
+=== Function: Find and configure a matching counter (FID #2)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_config_matching(unsigned long
counter_idx_base,
+                                             unsigned long
counter_idx_mask,
+                                             unsigned long
config_flags,
+                                             unsigned long
event_idx,
+                                             uint64_t event_data)
+----
+
+Find and configure a counter from a set of counters which is not
started
+(or enabled) and can monitor the specified event. The
`counter_idx_base`
+and `counter_idx_mask` parameters represent the set of counters
whereas
+the `event_idx` represent the event to be monitored and `event_data`
+represents any additional event configuration.
+
+The `config_flags` parameter represent additional counter
configuration
+and filter flags. The bit defintions of the `config_flags` parameter
are
+shown in the <<table_pmu_counter_cfg_match_flags>> below.
+
+[#table_pmu_counter_cfg_match_flags]
+.PMU Counter Config Match Flags
+[cols="3,1,2", width=90%, align="center", options="header"]
+|===
+| Flag Name                   | Bits       | Description
+| SBI_PMU_CFG_FLAG_SKIP_MATCH | 0:0        | Skip the counter
IMO, some additional clarification along the following lines will be
helpful.

SBI_PMU_CFG_FLAG_SKIP_MATCH should only be used when the caller is
already aware of the event to counter mapping (from previous time).
In that case, the counter id must be passed in `counter_idx_base` and
the `counter_idx_mask` should be set to 1.

matching
+| SBI_PMU_CFG_FLAG_CLEAR_VALUE| 1:1        | Clear (or zero) the
counter
+                                             value in counter
configuration
+| SBI_PMU_CFG_FLAG_AUTO_START | 2:2        | Start the counter after
+                                             configuring a matching
We can be bit explicit here
This flag doesn't modify the existing value of the counter.

counter
+| SBI_PMU_CFG_FLAG_SET_MINH   | 3:3        | Event counting
inhibited +
+                                             in M-mode
+| SBI_PMU_CFG_FLAG_SET_SINH   | 4:4        | Event counting
inhibited +
+                                             in S-mode
+| SBI_PMU_CFG_FLAG_SET_UINH   | 5:5        | Event counting
inhibited +
+                                             in U-mode
+| SBI_PMU_CFG_FLAG_SET_VSINH  | 6:6        | Event counting
inhibited +
+                                             in VS-mode
+| SBI_PMU_CFG_FLAG_SET_VUINH  | 7:7        | Event counting
inhibited +
+                                             in VU-mode
+| *RESERVED*                  | 8:(XLEN-1) | All non-zero values are
+                                             reserved for future use
+|===
+
+*NOTE:* The config_flags[3:7] bits are event filtering hints so
these can
+be ignored or overriden by the SBI implemenation for security
concerns or
+due to lack of event filtering support in underlying platform.
+
+*Returns* the `counter_idx` in `sbiret.value` upon success.
+
+In case of failure, the possible error codes returned in
`sbiret.error` are
+shown in the <<table_pmu_counter_cfg_match_errors>> below.
+
+[#table_pmu_counter_cfg_match_errors]
+.PMU Counter Config Match Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code            | Description
+| SBI_SUCCESS           | counter found and configured successfully.
+| SBI_ERR_INVALID_PARAM | set of counters has an invalid counter.
+| SBI_ERR_NOT_SUPPORTED | none of the counters can monitor specified
event.
+|===
+
+=== Function: Start a set of counters (FID #4)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_start(unsigned long counter_idx_base,
+                                   unsigned long counter_idx_mask,
+                                   unsigned long start_flags,
+                                   uint64_t initial_value)
+----
+
+Start or enable a sef of counters on the calling HART with the
specified
+initial value. The `counter_idx_base` and `counter_idx_mask`
parameters
+represent the set of counters whereas the `initial_value` parameter
+specifies the initial value of the counter.
+
+The bit defintions of the `start_flags` parameter are shown in the
+<<table_pmu_counter_start_flags>> below.
+
+[#table_pmu_counter_start_flags]
+.PMU Counter Start Flags
+[cols="3,1,2", width=90%, align="center", options="header"]
+|===
+| Flag Name                    | Bits       | Description
+| SBI_PMU_START_SET_INIT_VALUE | 0:0        | Set the initial value.
We can be bit explicit here

Set the initial value if true. The counter value is not modified if
false.

+                                              counters.
+| *RESERVED*                   | 1:(XLEN-1) | All non-zero values
are
+                                              reserved for future
use
+|===
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_start_errors>> below.
+
+[#table_pmu_counter_start_errors]
+.PMU Counter Start Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code              | Description
+| SBI_SUCCESS             | counter started successfully.
+| SBI_ERR_INVALID_PARAM   | some of the counters specified in
parameters
+                            are invalid.
+| SBI_ERR_ALREADY_STARTED | some of the counters specified in
parameters
+                            are already started.
+|===
+
+=== Function: Stop a set of counters (FID #4)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_stop(unsigned long counter_idx_base,
+                                   unsigned long counter_idx_mask,
+                                   unsigned long stop_flags)
+----
+
+Stop or disable a set of counters on the calling HART. The
`counter_idx_base`
+and `counter_idx_mask` parameters represent the set of counters. The
bit
+defintions of the `stop_flags` parameter are shown in the
+<<table_pmu_counter_stop_flags>> below.
+
+[#table_pmu_counter_stop_flags]
+.PMU Counter Stop Flags
+[cols="3,1,2", width=90%, align="center", options="header"]
+|===
+| Flag Name               | Bits       | Description
+| SBI_PMU_STOP_FLAG_RESET | 0:0        | Reset the counter to event
mapping.
+| *RESERVED*              | 1:(XLEN-1) | All non-zero values are
reserved
+                                         for future use
+|===
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_stop_errors>> below.
+
+[#table_pmu_counter_stop_errors]
+.PMU Counter Stop Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code              | Description
+| SBI_SUCCESS             | counter stopped successfully.
+| SBI_ERR_INVALID_PARAM   | some of the counters specified in
parameters
+                            are invalid.
+| SBI_ERR_ALREADY_STOPPED | some of the counters specified in
parameters
+                            are already stopped.
+|===
+
+=== Function: Read a firmware counter (FID #5)
+
+[source, C]
+----
+struct sbiret sbi_pmu_counter_fw_read(unsigned long counter_idx)
+----
+
+Provide the current value of a firmware counter in `sbiret.value`.
+
+The possible error codes returned in `sbiret.error` are shown in the
+<<table_pmu_counter_fw_read_errors>> below.
+
+[#table_pmu_counter_fw_read_errors]
+.PMU Counter Firmware Read Errors
+[cols="2,3", width=90%, align="center", options="header"]
+|===
+| Error code            | Description
+| SBI_SUCCESS           | firmware counter read successfully.
+| SBI_ERR_INVALID_PARAM | `counter_idx` points to a hardware counter
+                          or an invalid counter.
+|===
+
+=== Function Listing
+
+[#table_pmu_function_list]
+.PMU Function List
+[cols="5,2,1,2", width=80%, align="center", options="header"]
+|===
+| Function Name                   | SBI Version | FID | EID
+| sbi_pmu_num_counters            | 0.3         | 0   | 0x504D55
+| sbi_pmu_counter_get_info        | 0.3         | 1   | 0x504D55
+| sbi_pmu_counter_config_matching | 0.3         | 2   | 0x504D55
+| sbi_pmu_counter_start           | 0.3         | 3   | 0x504D55
+| sbi_pmu_counter_stop            | 0.3         | 4   | 0x504D55
+| sbi_pmu_counter_fw_read         | 0.3         | 5   | 0x504D55
+|===
+
 == Experimental SBI Extension Space (EIDs #0x08000000 - #0x08FFFFFF)
 
 No management.
--
Regards,
Atish


Re: [PATCH] riscv-platform-spec: Additional requirements to server extension

Abner Chang
 



Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月17日 週一 下午2:45寫道:
On 5/17/21 5:41 AM, Anup Patel wrote:
>
>
>> -----Original Message-----
>> From: Heinrich Schuchardt <xypron.glpk@...>
>> Sent: 17 May 2021 01:27
>> To: tech-unixplatformspec@...; Anup Patel
>> <Anup.Patel@...>; Sunil V L <sunilvl@...>;
>> renba.chang@...
>> Cc: tech-unixplatformspec@...
>> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] riscv-platform-spec:
>> Additional requirements to server extension
>>
>> Am 16. Mai 2021 19:13:47 MESZ schrieb Anup Patel <anup.patel@...>:
>>> Hi,
>>>
>>> Please note that we should consider that Guest/VM will be directly
>>> running in VS-mode (S-mode without hypervisor capabilities) so UEFI
>>> firmware will be running entirely in S-mode inside Guest/VM for
>>> virtualization. In other words, Guest/VM will not have any M-mode
>>> resources such as PMP, ePMP, etc. Various distros will expect UEFI
>>> services to work fine inside Guest/VM.
>>
>> At least U-Boot relies on OpemSBI for unaligned memory access and may use
>> it for sytem reset. Where will ecalls and exceptions be handled when running
>> in VS mode?
>
> The SBI calls for VS-mode will be provided by the HS-mode (KVM, Xvisor,
> Xen and other hypervisors).
>
> The OpenSBI provides SBI calls for HS-mode and provides other runtime
> features such as misaligned load/store emulation, TIME CSR emulations, etc.
>
> The boot-flow followed by U-Boot take care of virtualization as well.
> Particularly, the U-Boot S-mode is intended to run as-is unmodified in
> VS-mode.
>
> My point is that any UEFI implementation should consider this fact that
> inside Guest/VM there is no M-mode. This means any UEFI related
> requirements should only expect SBI calls and it should not matter who
> provides the SBI calls (OpenSBI or Hypervisors).
>
> Based on my understanding of EDK2 boot-flow, currently it is not as
> flexible as U-Boot + OpenSBI boot-flow. Since EDK2 is widely used
> as UEFI implementation, running directly in VS-mode should be
> supported by EDK2. Please correct me if I am wrong here.

Hi Anup,

OpenSBI and EDK2 are actually a peer, both of those are the boot firmware. On EDK2+OpenSBI solution, EDK2 uses OpenSBI as the library to leverage RISC-V platform code and SBI implementation. However, the system still boots based on the EDK2 architecture and execution phases.  Although OpenSBI is the library in EDK2, all of SBI calls are still go to OpenSBI. EDK2 and OpenSBI are in the one entity, just EDK2 provides firmware extension SBI to the later EFI drivers.

EDK2 is not necessary to be executed in VS mode, part of edk2 code stays in M-mode as same as OpenSBI. Another part runs in S-mode which dispatches S-Mode PEI drivers, S-Mode DXE drivers and M-Mode driver (management mode EFI driver). EDK2 can still start other HSM harts using firmware extension SBI for the vituralization at the end of post.

That would be difficult to have EDK2 runs on VS, there are many EDK2 drivers that communicate with the hardware operation region which is better isolated from other S-mode EFI drivers. Some of EFI driver are executed in management mode (could be M-mode in RISC-V) for the security and manageability. We don't want to see any S-Mode entities such as the S-mode EFI driver which is loaded from PCI option card can tamper or reverse engineering those code. Some memory regions are determined during POST and those memory region should be only accessed in M-mode to secure the content and prevent from S-mode EFI driver/software to modify it (e.g. management mode memory and PRM, the latter needs ePMP for the shared code/data).

Firmware extension SBI is only used for the EFI driver during POST, thus it is not a problem if EDK2 is executed in the M/S mode.  Also, as we discussed in another thread, we need OpenSBI allows switching to M-mode for the next phase only for the boot hart, boot firmware has to switch to S-mode before handing off to the next stage.

There are still some details of OpenSBI-EDK2 collaboration for the above need to discuss…

 


Currently EDK II provides OpenSBI as part of its SEC (Security) code in
edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi.

When the hypervisor provides the SEC code we will need to enter directly
into the PEI (Pre-EFI Initialization Environment).

Cf.
https://gblobscdn.gitbook.com/assets%2F-M5spcVt2sqlUZOWmnXY%2F-M5sphJDWD7_iUuoREya%2F-M5spjTOFjRbcY8ckkSh%2Fimage3.png?alt=media

This will require a new platform variant but should not require changes
is main EDK II.

Right, if we have EDK2 in VS, we will need another platform for this.  But the platform that conforms with what I mentioned in above should be also supported, that is the main stream edk2 RISC-V variant to afford the current OEM implementations (PC/notebook and server).


Regards,

Abner



Best regards

Heinrich

>
> Regards,
> Anup
>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Regards,
>>> Anup
>>>
>>> Get Outlook for Android<https://aka.ms/AAb9ysg>
>>> ________________________________
>>> From: tech-unixplatformspec@...
>>> <tech-unixplatformspec@...> on behalf of Sunil V L
>>> <sunilvl@...>
>>> Sent: Sunday, May 16, 2021 7:17:56 PM
>>> To: renba.chang@... <renba.chang@...>
>>> Cc: tech-unixplatformspec@...
>>> <tech-unixplatformspec@...>
>>> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH]
>>> riscv-platform-spec: Additional requirements to server extension
>>>
>>> Hi Abner,
>>>
>>> On Tue, May 11, 2021 at 09:48:42AM +0800, renba.chang@... wrote:
>>>> From: Abner Chang <renba.chang@...>
>>>>
>>>> Add more server extensions to align with current server firmware
>>> implementation and the future technology.
>>>>
>>>> @Sunil, I would like to add below placeholders to server extension in
>>> order to align with the server platform implementation.
>>>>
>>>> 1. RISC-V port of Management Mode EFI protocols, most of servers had
>>> implemented EFI MM driver to handle the critical errors, security,
>>> in-band BMC operations, remote management and etc features.
>>>> Some of those features have dependencies with chipset or
>>> processor-arch, but some of those are chipset and processor-arch
>>> agnostic. Having RISC-V EFI MM protocols as the server extension to
>>> support the latter use case for cross platform FW MM driver
>>> implementation.
>>>>
>>>> 2. PRM (Platform Runtime Mechanism)
>>>>     Addition to the use cases implemented based on #1, UEFI PRM is
>>> provided to enable OS capability to invoke OS agnostic FW procedures
>>> for ACPI or error handling directly without generating software
>>> management mode event. Leverage ePMP shared code/data regions for
>>> M-Mode/S-Mode entities to co-manage PRM data/code region.
>>>>
>>>
>>> My understanding is, these features are introduced to reduce some of
>>> the issues with SMM mode in x86. I am not sure whether we will have
>>> similar issues in risc-v and need to make this feature mandatory. I
>>> think each of these need a separate discussion involving SBI experts. I
>>> understand your intention here is to have a section to trigger further
>>> investigation. If so, it looks fine to me unless someone else have an
>>> objection.
>>>
>>>> 3. RTC (Real Time Clock)
>>>>     Real time clock is the server basic system peripheral to provide
>>> the real date/time information for server to manage the system date,
>>> time and time zones settings for different regions through the local
>>> POST time firmware utility, NTP or the remote management such as
>>> Redfish.
>>>>
>>> Agree.
>>>
>>> Regards
>>> Sunil
>>>
>>>> Signed-off-by: Abner Chang <renba.chang@...>
>>>> Cc: Sunil V L <sunilvl@...>
>>>> ---
>>>>   riscv-platform-spec.adoc | 7 +++++++
>>>>   1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>>>> index 160c74a..55c5735 100644
>>>> --- a/riscv-platform-spec.adoc
>>>> +++ b/riscv-platform-spec.adoc
>>>> @@ -245,8 +245,15 @@ implemented but it can return
>> EFI_UNSUPPORTED.
>>>>   implemented but it can return EFI_UNSUPPORTED.
>>>>   |===
>>>>
>>>> +====== Management Mode
>>>> +====== UEFI Platform Runtime Mechanism
>>>> +* PRM Module
>>>> +* ACPI PRMT Table
>>>> +* Enhanced PMP Shared Memory Region
>>>> +
>>>>   ==== System Peripherals
>>>>   * PCI-E
>>>> +* Real Time Clock
>>>>
>>>>   ==== Secure Boot
>>>>   * TEE
>>>> --
>>>> 2.19.0.windows.1
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>


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

Mayuresh Chitale
 

Base spec:
- UART
- Clock and Timers

Server extension:
- Clock and Timers

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

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..9129284 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -55,9 +55,40 @@ include::profiles.adoc[]

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

==== Boot Process
* Firmware
@@ -246,6 +277,13 @@ implemented but it can return EFI_UNSUPPORTED.
|===

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

==== Secure Boot
--
2.17.1


[PATCH v4 1/2] Updating contributors

Mayuresh Chitale
 

Adding myself to list of contributors.

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index 3d19411..0197923 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -26,7 +26,8 @@ Paul Walmsley,
Andrew Waterman,
Kumar Sankaran,
Alistair Francis,
-Sunil V L.
+Sunil V L,
+Mayuresh Chitale.

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.17.1


[PATCH v4 0/2] System Peripherals

Mayuresh Chitale
 

This patch describes requirements for the system peripherals
like UART, clock and timers for the Linux-2022 platform
base spec and the server extension.

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

Changes in V3:

Base spec:
- Clarified minimum requirement for counter resolution.

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

Changes in V2:

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

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

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

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

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

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

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

--
2.17.1


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

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

 



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

Mayuresh Chitale
 





On Mon, May 17, 2021 at 8:32 PM Jonathan Behrens <behrensj@...> wrote:
> +** Platforms are required to provide atleast a 10ns resolution 64-bit counter

nit: "at least a" => "an at least" (the former could be misunderstood as saying to have to provide an exactly 10ns timer, but can also provide other timers if you want)

Thanks. I will correct it.

On Mon, May 17, 2021 at 10:20 AM Mayuresh Chitale via lists.riscv.org <mchitale=ventanamicro.com@...> wrote:
Base spec:
- UART
- Clock and Timers

Server extension:
- Clock and Timers

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

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..328b1dc 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -55,9 +55,40 @@ include::profiles.adoc[]

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

 ==== Boot Process
 * Firmware
@@ -246,6 +277,13 @@ implemented but it can return EFI_UNSUPPORTED.
 |===

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

 ==== Secure Boot
--
2.17.1







Re: [PATCH v4] Base boot and runtime requirements - initial commit

Rahul Pathak
 

Alright, Thanks

On Mon, May 17, 2021 at 9:54 PM Heinrich Schuchardt <xypron.glpk@...> wrote:
On 11.05.21 05:41, Rahul Pathak wrote:
> Initial changes for the Base Boot & Runtime requirements.
> The sections which are currently in-progress are marked as TBD.
> These changes can serve as the starting point and more details/changes
> can be done tailored for RISC-V.
>
> Updated the section "Storage and Partition" along with details on
> SBI Extensions in Runtime Section.
>
> There is an patch to add RISC-V details in the EBBR spec sent by Atish.
> That patch is not yet merged in the EBBR. The section on the
> "Startup Protocol" in this spec will refer to the requirements there
> and currently that link is marked as TBD.
>
> Corrected SBI Spec version
>
> Signed-off-by: Rahul Pathak <rpathak@...>
> ---
>  riscv-platform-spec.adoc | 134 +++++++++++++++++++++++++++++++++++++--
>  1 file changed, 127 insertions(+), 7 deletions(-)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 160c74a..8827476 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -34,6 +34,36 @@ include::profiles.adoc[]
>  // Linux-2022 Platform
>  == Linux-2022 Platform
>
> +=== Terminology
> +[cols="1,2", width=80%, align="left", options="header"]
> +|===
> +|TERM      | DESCRIPTION
> +|SBI       | Supervisor Binary Interface
> +|UEFI      | Unified Extensible Firmware Interface
> +|ACPI      | Advanced Configuration and Power Interface
> +|SMBIOS    | System Management Basic I/O System
> +|DTS       | Devicetree source file
> +|DTB       | Devicetree binary
> +|RVA22     | RISC-V Application 2022
> +|EE        | Execution Environment
> +|RV32GC    | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
> +|RV64GC    | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
> +|===
> +
> +=== Specifications
> +[cols="1,2", width=80%, align="left", options="header"]
> +|===
> +|SPECIFICATION      | VERSION
> +|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification]         | v2.9
> +|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification]  | v0.3
> +|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification]                    | v0.3-rc0
> +|link:[RVA22 Specification]                                                                                   | TBD
> +|link:https://arm-software.github.io/ebbr/[EBBR Specification]                                                | v2.0.0-pre1
> +|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification]              | v6.4
> +|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification]    | v3.4.0
> +|link:[Platform Policy]                                                                                       | TBD
> +|===
> +
>  // Base feature set for Linux-2022 Platform
>  === Base
>  ==== Architecture
> @@ -59,14 +89,104 @@ include::profiles.adoc[]
>  * Timers
>  * Watchdog Timers
>
> -==== Boot Process
> -* Firmware
> -* Boot-Loader
> -* Discovery Mechanisms
> +==== Boot and Runtime Requirements
> +- The base specification defines the interface between the firmware and the
> +operating system suitable for the RISC-V platforms with rich operating
> +systems.
> +- These requirements specifies the required boot and runtime services, device
> +discovery mechanism, etc.
> +- The requirements are operating system agnostic, specific firmware/bootloader
> +implementation agnostic.
> +- Any RV32GC or RV64GC platform seeking compliance with the base specification
> +require to implement all three privilege modes i.e. M, S and U mode.
> +- For the generic mandatory requirements this base specification will refer to
> +the EBBR Specification. Any deviation from the EBBR will be explicitly
> +mentioned in the requirements.
> +- Specifications followed are mentioned in the
> +<<Specifications,Specification Section>>
> +
> +
> +===== Firmware
> +- UEFI Platform is required to adhere to RISC-V Platform requirements on
> +calling conventions, ABI support specific to RISC-V. Refer Chapter - 2.3.7
> +RISC-V Platforms of UEFI specification.
> +- For compliance with base specification platform is required to implement
> +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements],
> +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements]
> +and following
> +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
> +
> +====== Storage and Partitioning
> +- Firmware is required to implement requirements as per the
> +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
> +requirements.
> +- For shared storage base spec requires GPT partitioning, MBR is deprecated.

"deprecated" implies is required but will be removed in next version.
Use instead:

"MBR support is not required."

> +
> +===== Boot Services
> +- All functions defined as boot services are required. Methods for
> +unsupported or unimplemented behavior must return an appropriate error
> +code.
> +
> +====== Startup Protocol
> +- UEFI firmware could be executed in either Machine mode or Supervisor mode
> +during the entire POST, according to the hart capability and the platform
> +design. For detailed requirements on startup protocol refer link:[**TBD** - EBBR LINK FOR STARTUP PROTOCOL]
> +and UEFI chapter 2.3.7 RISC-V Platforms.
> +
> +
> +====== Memory Map
> +- Base specification requires UEFI environment to provide a system memory map
> +as per the requirements link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
> +
> +
> +===== Discovery Mechanisms
> +- Devicetree is the required mechanism for system description.
> +- System is required to implement link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements]
> +to comply with this base specification. Also refer Devicetree tables section in
> +chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
> +
> +===== Runtime Services
> +====== SBI
>
> -==== Runtime services
> -* SBI
> -* UEFI
> +- Required SBI spec version is 0.3 or higher.
> +- Legacy Extensions from the SBI Specification are deprecated.

Please, remove this sentence because we do not require to implement
this.

Best regards

Heinrich

> +- Required SBI extensions -
> +
> +[cols="1,2", width=80%, align="left", options="header"]
> +|===
> +|EXTENSION     |    CONDITIONS
> +|SBI TIME      |    if **stimecmp** CSR not available
> +|SBI IPI       |
> +|SBI RFENCE    |
> +|SBI HSM       |
> +|SBI SRST      |
> +|SBI PMU       |
> +|===
> +
> +- Required responsibilities of M-Mode runtime also includes -
> +    ** Interrupt and Exception Delegation
> +    ** Misaligned Load & Stores handling
> +    ** Missing CSRs emulation
> +    ** PMP Configuration
> +
> +- Wherever applicable firmware must implement UEFI interfaces over similar
> +interfaces and services present in the SBI specification. For example, UEFI
> +runtime services must implement ResetSystem() via SBI Reset extension.
> +
> +====== UEFI
> +- Firmware must conform to the
> +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
> +- Firmware must meet the requirements for
> +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings]
> +to avoid conflict between the firmware and OS when accessing the mapped
> +devices.
> +- Compliant UEFI runtime environment must meet the requirements for the
> +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
> +- Compliant implementation must meet the Realtime Clock requirements
> +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface]
> +if RTC is present in the system.
> +- OS should prioritize calling the UEFI interfaces before the SBI or Platform
> +specific mechanisms.
>
>  // Server extension for Linux-2022 Platform
>  === Server Extension
>


Re: [PATCH v4] Base boot and runtime requirements - initial commit

Heinrich Schuchardt
 

On 11.05.21 05:41, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes
can be done tailored for RISC-V.

Updated the section "Storage and Partition" along with details on
SBI Extensions in Runtime Section.

There is an patch to add RISC-V details in the EBBR spec sent by Atish.
That patch is not yet merged in the EBBR. The section on the
"Startup Protocol" in this spec will refer to the requirements there
and currently that link is marked as TBD.

Corrected SBI Spec version

Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 134 +++++++++++++++++++++++++++++++++++++--
1 file changed, 127 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..8827476 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -34,6 +34,36 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|EE | Execution Environment
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|link:[Platform Policy] | TBD
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -59,14 +89,104 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the
+operating system suitable for the RISC-V platforms with rich operating
+systems.
+- These requirements specifies the required boot and runtime services, device
+discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader
+implementation agnostic.
+- Any RV32GC or RV64GC platform seeking compliance with the base specification
+require to implement all three privilege modes i.e. M, S and U mode.
+- For the generic mandatory requirements this base specification will refer to
+the EBBR Specification. Any deviation from the EBBR will be explicitly
+mentioned in the requirements.
+- Specifications followed are mentioned in the
+<<Specifications,Specification Section>>
+
+
+===== Firmware
+- UEFI Platform is required to adhere to RISC-V Platform requirements on
+calling conventions, ABI support specific to RISC-V. Refer Chapter - 2.3.7
+RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform is required to implement
+link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements],
+link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements]
+and following
+link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Storage and Partitioning
+- Firmware is required to implement requirements as per the
+link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+requirements.
+- For shared storage base spec requires GPT partitioning, MBR is deprecated.
"deprecated" implies is required but will be removed in next version.
Use instead:

"MBR support is not required."

+
+===== Boot Services
+- All functions defined as boot services are required. Methods for
+unsupported or unimplemented behavior must return an appropriate error
+code.
+
+====== Startup Protocol
+- UEFI firmware could be executed in either Machine mode or Supervisor mode
+during the entire POST, according to the hart capability and the platform
+design. For detailed requirements on startup protocol refer link:[**TBD** - EBBR LINK FOR STARTUP PROTOCOL]
+and UEFI chapter 2.3.7 RISC-V Platforms.
+
+
+====== Memory Map
+- Base specification requires UEFI environment to provide a system memory map
+as per the requirements link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+
+===== Discovery Mechanisms
+- Devicetree is the required mechanism for system description.
+- System is required to implement link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements]
+to comply with this base specification. Also refer Devicetree tables section in
+chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI

-==== Runtime services
-* SBI
-* UEFI
+- Required SBI spec version is 0.3 or higher.
+- Legacy Extensions from the SBI Specification are deprecated.
Please, remove this sentence because we do not require to implement
this.

Best regards

Heinrich

+- Required SBI extensions -
+
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|EXTENSION | CONDITIONS
+|SBI TIME | if **stimecmp** CSR not available
+|SBI IPI |
+|SBI RFENCE |
+|SBI HSM |
+|SBI SRST |
+|SBI PMU |
+|===
+
+- Required responsibilities of M-Mode runtime also includes -
+ ** Interrupt and Exception Delegation
+ ** Misaligned Load & Stores handling
+ ** Missing CSRs emulation
+ ** PMP Configuration
+
+- Wherever applicable firmware must implement UEFI interfaces over similar
+interfaces and services present in the SBI specification. For example, UEFI
+runtime services must implement ResetSystem() via SBI Reset extension.
+
+====== UEFI
+- Firmware must conform to the
+link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for
+link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings]
+to avoid conflict between the firmware and OS when accessing the mapped
+devices.
+- Compliant UEFI runtime environment must meet the requirements for the
+link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements
+link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface]
+if RTC is present in the system.
+- OS should prioritize calling the UEFI interfaces before the SBI or Platform
+specific mechanisms.

// Server extension for Linux-2022 Platform
=== Server Extension


Re: Next Platform HSC Meeting on Monday May 17 2021 9AM PST

Abner Chang
 



Kumar Sankaran <ksankaran@...> 於 2021年5月15日 週六 下午1:26寫道:
Hi All,
The next platform HSC meeting is scheduled on Monday May 17th 9AM PST.
Please note the new time of 9AM PST for this meeting. This change to 9AM PST
is only for the May 17th session due to another conflicting meeting at 8AM
PST. Sorry for any inconvenience due to this change in timing and I hope all
of you can make it.
Hi Kunar,
I am not able to join at this time slot. Below is my status update,

1. Restructure the spec of PLIC/CLINT/MTIME to address the feedback from Greg.
2. Sent out the patch of Additions to Server Extension for review.

Regards,
Abner
 

Here are the details:

Agenda and minutes kept on the github wiki:
https://github.com/riscv/riscv-platform-specs/wiki

Here are the slides:
https://docs.google.com/presentation/d/1ElSPEKqlnjQkkA6QWIlqdBiD5knQb_NIvXJfXR9hw-s/edit#slide=id.gc525db7f82_0_281

Meeting info
Zoom meeting: https://zoom.us/j/2786028446
Passcode: 901897

Or iPhone one-tap :
US: +16465588656,,2786028466#  or +16699006833,,2786028466# Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656  or +1 669 900 6833
Meeting ID: 278 602 8446
International numbers available:
https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_

Regards
Kumar






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

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

 



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

Jonathan Behrens <behrensj@...>
 

> +** Platforms are required to provide atleast a 10ns resolution 64-bit counter

nit: "at least a" => "an at least" (the former could be misunderstood as saying to have to provide an exactly 10ns timer, but can also provide other timers if you want)


On Mon, May 17, 2021 at 10:20 AM Mayuresh Chitale via lists.riscv.org <mchitale=ventanamicro.com@...> wrote:
Base spec:
- UART
- Clock and Timers

Server extension:
- Clock and Timers

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

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..328b1dc 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -55,9 +55,40 @@ include::profiles.adoc[]

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

 ==== Boot Process
 * Firmware
@@ -246,6 +277,13 @@ implemented but it can return EFI_UNSUPPORTED.
 |===

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

 ==== Secure Boot
--
2.17.1







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

Mayuresh Chitale
 

Base spec:
- UART
- Clock and Timers

Server extension:
- Clock and Timers

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

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 160c74a..328b1dc 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -55,9 +55,40 @@ include::profiles.adoc[]

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

==== Boot Process
* Firmware
@@ -246,6 +277,13 @@ implemented but it can return EFI_UNSUPPORTED.
|===

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

==== Secure Boot
--
2.17.1


[PATCH v3 1/2] Updating contributors

Mayuresh Chitale
 

Adding myself to list of contributors.

Signed-off-by: Mayuresh Chitale <mchitale@...>
---
contributors.adoc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contributors.adoc b/contributors.adoc
index 3d19411..0197923 100644
--- a/contributors.adoc
+++ b/contributors.adoc
@@ -26,7 +26,8 @@ Paul Walmsley,
Andrew Waterman,
Kumar Sankaran,
Alistair Francis,
-Sunil V L.
+Sunil V L,
+Mayuresh Chitale.

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.17.1


[PATCH v3 0/2] System Peripherals

Mayuresh Chitale
 

This patch describes requirements for the system peripherals
like UART, clock and timers for the Linux-2022 platform
base spec and the server extension.

Changes in V3:

Base spec:
- Clarified minimum requirement for counter resolution.

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

Changes in V2:

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

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

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

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

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

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

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

--
2.17.1

901 - 920 of 1850