1. Messages
  2. [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure

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

Philipp Tomsich <philipp.tomsich@...>
 



On Mon 28. Jun 2021 at 23:31, Jonathan Behrens <behrensj@...> wrote:


On Mon, Jun 28, 2021 at 5:26 PM Greg Favor <gfavor@...> wrote:
On Mon, Jun 28, 2021 at 2:14 PM Jonathan Behrens <behrensj@...> wrote:
I'm not sure I follow. I understand that the low-level and high-level discovery mechanisms are different, but is there a reason that the pointer to the low-level discovery method needs to be passed via a CSR? Instead, couldn't we just say for instance, "at boot register a5 contains a pointer to the low-level configuration structure."

The issue is that coming out of reset, early M-mode software needs to be able to find the config structure.  If the pointer is in a GPR, who sets the correct value into that register and how does that piece of software find out the correct value to put into the register?  In many systems this CSR value will be hardwired, or will be initialized by an implementation-specific mechanism, before the hart comes out of reset.  (For example, in some higher-end Linux-class systems there may be a platform microcontroller that brings up the system from power-on, establishes a secure boot root of trust, ..., and prepares the harts to be released from reset.)

Couldn't the reset state itself just have a5=<pointer>? I don't see why that would be substantially harder to implement than a reset state with CSR[0x750]=<pointer>.

Now we’d need to save $a5 somewhere we can get at it later on… with a CSR, the value can be retrieved whenever needed. Note that I’d love to have a sane C runtime (with at least a stack somewhere in OCM) at initialization, but I expect parts of the ecosystem (most likely hardware vendors) will not want to impose any further restrictions on initial boot firmware.

In other words: doing so would impose further requirements on the early boot firmware. Keeping it in a CSR decouples the extension/unified discovery fully.

Philipp.
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.