In consideration of low-end systems that may point into some memory-mapped serial storage, I would rather avoid this. It’s also going to cause eventual discussions, once the first devices with

There is no technical requirement for an alignment stricter than byte. Given that we are operating on a ‘config message’, there is also no implementation benefit of stricter alignment. Reusing any

That's one example of a high-level discovery method used by, for example, some Linux systems. This low-level discovery method is used by early boot flow software and is used to populate

Agreed. That's OK. The extension would then define the low two bits as "00" and as "Reserved for future standard use". Greg

Why does it need to be a CSR? In other parts of the boot flow the device tree pointer is passed via a normal general purpose register. Why can't the same be done here? Jonathan

Many systems will have this CSR as only readable (along the lines of my earlier P.S.). But flexibility is allowed for possible use cases where the pointer wants to be changeable by M-mode to point to

One addition: If the CSR contains 0, software should assume there is no configuration structure. I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits.

Yes on both counts. Profile specs (or at least A profile specs) would require this ISA extension. Platforms would require, if they so choose, use of the RISC-V standard software low-level discovery

Why is the CSR writable? What's the use case for that? (Hypervisor writing it for an M mode system underneath? But then it's still not writable in M mode.) Tim

On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...> "Some implementations may hardwire this CSR to a suitable value." This should have been better worded as: "Upon reset this CSR is initialized

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

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

We were reading a lot into "Memory regions that do not fit into regular main memory, for example, device scratchpad RAMs, are categorized as I/O regions." I have a PR with edits to avoid this type

Direct access seems fine for the reasons stated. Can I gather from this that the expectation is that the vast majority of non-state extensions will have no need or desire for enables? Thus no value

On 2021-06-16 9:15 p.m., John Hauser wrote: I suggested that the stateen CSRs are not needed and cannot be trusted. This alternative wasn't rejected, per se.

Josh Scheid wrote: The AIA draft (Advanced Interrupt Architecture) currently defines 425 indirectly accessed registers for RV32, and some of them are ones we knew we wanted to be able to index

Note that there would be just one bit per relevant extension - irrespective of how many CSRs it adds. As far as an extension that gobbles up a lot CSR numbers, it will be a natural and appropriate

An acceptable outcome, but I don't think extensions with large or potentially-growing CSR space requirements should plan to eat up CSR space and should instead use indirection when it makes sense

Past discussions considered 4 CSRs to last for a long time, i.e. we can place bets on whether that lasts >30 years, >20 years or >10 years. An option, not cast in concrete, for 8 CSRs provides one

John may have a more nuanced answer, but No. Greg