- [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
Jonathan Behrens <behrensj@...>
On Mon, Jun 28, 2021 at 5:26 PM Greg Favor <gfavor@...
On Mon, Jun 28, 2021 at 2:14 PM Jonathan Behrens <behrensj@...
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>.
Join email@example.com to automatically receive all group messages.