1. posterid:4687342
  2. Messages

Re: Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure

mark
 

so how do we communicate this to the world?

csr is an ISA extension
config tab is a software only Non-ISA doc rule required only by a platform spec?

So could you do discovery in some other way and be profile compatible but not platform compatible?

or since this is a hybrid spec with ISA and non-ISA and gets ratified together it is different? (btw The new regs already cover this kind of doc). Would we want the policy to say that extensions ratified in a hybrid spec require the implementer to implement both ISA and non-ISA to claim RISC-V compatible?

I am the first one in favor of separation of ISA and non-ISA but I must admit this one makes me feel uncomfortable in just saying it is just SW and allow the possibility of variations both being RISC-V (profile) compatible.

or am I misunderstanding?

Mark


On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...> wrote:
The new "unified RISC-V low-level discovery method" being developed by tech-config (for use by all extensions that have information that needs to be easily discoverable by software), is almost completely software-based.  The compressed binary config structure (containing all the discovery information) will reside somewhere in system physical address space and will be read and decoded (based on a standardized RISC-V schema) by an M-mode parser/decoder into all the individual discoverable items available for use by software.

Typically M-mode software, during the boot flow, may make use of some of this information, but much of that information will be populated into a high-level discovery structure for use by other software components in the system (e.g. Device Tree or ACPI tables in Linux-class systems; Device Tree or some other suitable structure in embedded systems).  Other agents, such as an external debugger, may also read and parse this structure for discovering Debug and Trace architecture related information.

To support this, each hart needs to have a CSR that provides an address pointer to the memory-resident config data structure - which can reside anywhere in system address space and may physically reside on or off chip in whatever suitable form of storage.  This fast track extension standardizes this CSR.  This email (I'm helping out the people developing the overall discovery method) starts a prelim review of this extension on the tech-priv and tech-config email lists.

The proposed official extension name is 'Smdisc'.

The 'mconfigptr' CSR is an MXLEN-wide R/W M-mode CSR that provides a system physical address pointer to a memory-resident config data structure to be used by a software method for low-level discovery of configuration information about harts and the rest of the system.  Some implementations may hardwire this CSR to a suitable value.  The assigned CSR number is 0x750.

Greg

P.S. The Debug Architecture already contains config structure pointer registers in the Debug Module for use by an external debugger.
Join tech-privileged@lists.riscv.org to automatically receive all group messages.