Control and Status Registers

[Ammar Kurd]

Hello everyone,

I am working in RISC-V integer base implementation right now and I am confused over the CSR instructions, so I would like to ask what are the control and status registers needed? how many are there in RISC-V? I had a look at the RISC-V Instruction Set Manual Volume II: Privileged Architecture, but I got confused even more. Sorry for asking such a noob question but I need help obviously.

Thanks in advance.

[Stefan O'Rear]

On Tue, Nov 15, 2016 at 11:31 PM, Ammar Kurd <kurd....@gmail.com> wrote:
> Hello everyone,
>
> I am working in RISC-V integer base implementation right now and I am
> confused over the CSR instructions

CSRs are extra registers that can't be used for normal instructions
because they have special functions.

> so I would like to ask what are the
> control and status registers needed?

The base architecture defines a CSR space of 4096 CSRs. A core will
not implement all of them; unimplemented CSR addresses should be
treated as illegal instructions.

Most of the CSR numbers are reserved for future standardization. You
must not implement them unless they have the defined behavior.

You don't need any CSRs for RV32E. For RV64I or RV32I you need TIME,
CYCLE, and INSTRET; for RV32I you need TIMEH, CYCLEH, and INSTRETH as
well; and if you have RVF or RVD you need FCSR.

The reference privileged architecture defines significantly more, but
you don't need to implement it. The minimum is 0 for a very small
core and 4 for a general-purpose 64-bit core.

Other CSR numbers are reserved for implementors. You could define CSR
0x7C0 to do something relevant to your specific design.

> how many are there in RISC-V?

You can have _up to_ 4096 CSRs.

It's one of RISC-V's main extension points.

-s

[Ray Van De Walker]

It's true that the RV32E ISA has no requirement for CSRs.

However a real RV32E CPU does:
It looks to me like it needs at least the interrupt PC image mepc or equivalent.
Otherwise an interrupt will not have linkage to return.
Mstatus is needed for a global interrupt enable and disable.
(It's that or the "A" ISA to get concurrency controls.)
The interrupt mip and interrupt-enable mie, are probably needed, too.

I also favor the timer and mtvec.
A RISC-V port of any RTOS is very likely to use the standard timer.
Mtvec and position-independent code permit multiple firmware images to share memory.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CADJ6UvMNp_ShDU%2BdWTvrd97Fm%3DLr6sOnz0PhRx8rbfE4HKmasg%40mail.gmail.com.

[Sean Halle]

Thanks for the info about CSR.  Do you happen to know which CSRs are required for the standard RISC-V Linux?  In other words, the existing RISC-V Linux kernel is compiled such that the downloadable binary accesses particular CSR registers.  Is there a list somewhere of which ones?

[Stefan O'Rear]

On Fri, Nov 18, 2016 at 2:15 AM, Sean Halle <sean...@gmail.com> wrote:
>
> Thanks for the info about CSR. Do you happen to know which CSRs are
> required for the standard RISC-V Linux? In other words, the existing RISC-V
> Linux kernel is compiled such that the downloadable binary accesses
> particular CSR registers. Is there a list somewhere of which ones?

The Linux kernel uses all of the S-mode CSRs except sedeleg and
sideleg, since the S-mode CSR planning appears to have been driven by
Linux requirements.

BBL uses more of them, but BBL also does far more than I think it
needs to, and I'd very much like to see someone attempt to build a
system that boots in S-mode.

-s

[Sean Halle]

Thanks, Sefan :-)  

That clears things up on the Linux Front -- we have to implement all of the S mode CSRs.  However, I'm not familiar with BBL.  Do you believe that BBL is something that needs to be supported in a data center class server?   If so, which extra CSRs does it use?

Thanks,

Sean

[Stefan O'Rear]

On Fri, Nov 18, 2016 at 5:12 PM, Sean Halle <sean...@gmail.com> wrote:
>
> Thanks, Stefan :-)

>
> That clears things up on the Linux Front -- we have to implement all of the
> S mode CSRs. However, I'm not familiar with BBL. Do you believe that BBL
> is something that needs to be supported in a data center class server? If
> so, which extra CSRs does it use?

There's an ongoing debate about the precise role of above-S-mode
monitor code in the future RISC-V ecosystem. I am, for now, in the
"rather it not be strictly required" camp.

Data center class servers are likely to have various forms of remote
management, which might take the form of an M-mode monitor, an
above-M-mode monitor, external hardware, or something I haven't even
thought of. Trying to handle all of the requirements prior to
implementation experience is likely to just create complexity, though.

The current Linux port expects something with the downward-facing
interface of BBL. This interface is partially documented, missing a
few extensibility points (SBILIB is not self-describing and the kernel
takes no arguments), and requires a M-mode monitor, so I would rather
it not become a frozen standard as-is.

BBL uses quite a few CSRs which were undocumented in the 1.9.0 era but
I think they're documented now. Suggest searching the code for "csr"
instructions.

SiFive has a fork of BBL for their dev kits. QEMU will likely have a
fork of its own. Don't be squeamish about doing the same to support
your hardware in these early days.

-s

[Sean Halle]

Got it, thank you :-)

So, if I understand correctly, you're basically saying that everyone has their own approach to boot loading.  The boot loader from Berkeley uses CSRs that they added that are outside the 1.9 spec.  The boot loader from SiFive uses different CSRs.  And you recommend that we do our own boot loader, as long as it conforms to the interface that the RISC-V Linus kernel is expecting.  Then we're free to use whichever CSRs we deem most useful.

But, if we want to reuse one of the existing bootloaders, then we have to search the code and track down the CSRs they used, and be sure we implement those.  Perhaps by taking their Chisel code for the CSR implementation.

Is that pretty much it?

Thanks,

Sean

 

[Stefan O'Rear]

On Fri, Nov 18, 2016 at 11:54 PM, Sean Halle <sean...@gmail.com> wrote:
>
> Got it, thank you :-)
>
> So, if I understand correctly, you're basically saying that everyone has
> their own approach to boot loading. The boot loader from Berkeley uses CSRs
> that they added that are outside the 1.9 spec. The boot loader from SiFive
> uses different CSRs. And you recommend that we do our own boot loader, as

No, the Berkeley and SiFive boot loaders use MMIOs which are not
defined by the privilege spec. (0x100C is a config string pointer,
the timers and IPI mechanism are memory mapped, the SiFive BBL has a
driver for a memory-mapped UART, etc).

The CSRs are all documented in 1.9.1. I think; haven't actually checked.

> long as it conforms to the interface that the RISC-V [Linux] kernel is

> expecting. Then we're free to use whichever CSRs we deem most useful.
>
> But, if we want to reuse one of the existing bootloaders, then we have to
> search the code and track down the CSRs they used, and be sure we implement
> those. Perhaps by taking their Chisel code for the CSR implementation.

You could use BBL if you want, but if you can, right now I think the
community would benefit more from a fresh viewpoint on the bootloader
and platform hardware.

-s

[Raghav Hrishi]

Hello!
I have been working on the conversion of FreeRTOS for the RISCV 1.9 Privileged Architecture as it is present only for the RISCV 1.7 Privileged Architecture. I have added some CSRs instead of a few registers that is not present in this version like mtimecmp,mtime,mtohost and mfromhost. I  am designing this for my personal use. I have made the necessary changes and i am able to compile it. However, when i run it on spike, i am getting some runtime error.  I presume it is because of the 'mret' that i have used instead of all 'eret' present.
Can someone please help me with this?

[Stefan O'Rear]

It is difficult to debug these things remotely, and I sadly cannot
commit time to getting FreeRTOS running locally to debug. (RISC-V
handholding might be a good business opportunity for someone while we
get the toolchain and documentation in shape).

From what you've said: Is any part of FreeRTOS running in S-mode?
"mret" is only for code running in M-mode; if your trap handler is
running in S-mode you would use "sret" instead. (This is done to
satisfy Popek-Goldberg requirements.)

Otherwise more details on what the "some runtime error" is would help.
Generally, if you give us a list of instructions which can be followed
on a blank Linux VM to set up a situation where the error occurs, that
will make remote troubleshooting vastly easier; I don't want to spend
the time to understand FreeRTOS' build requirements, but I can run a
shell script in a sandbox no problem.

-s

[Raghav Hrishi]

This is what I get when i run it using spike.

[Stefan O'Rear]

On Thu, Dec 1, 2016 at 9:15 PM, Raghav Hrishi
<kookaburr...@gmail.com> wrote:
> This is what i get when i compile it using spike.

"pk" is a virtual Linux kernel. Is FreeRTOS a Linux user-mode
executable? If so, pk is correct, if not pk should not be used.

If FreeRTOS is intended to be entered in M-mode, it should be run
using Spike directly as you did in the first example. You'll want to
run it under a C++ debugger to see where the exception is being thrown
- from the name, "trap_store_access_fault", I'd guess you're doing
something incorrect with memory.

If FreeRTOS is intended to be entered in S-mode (as Linux is), it
should be run using "spike bbl".

-s

[Raghav Hrishi]

Do you suggest that I  make changes in the memory allocations that I have assigned ? I feel that there is some problem with the return command. I have changed 'eret' to 'mret' as I read that mret is essential. I made the changes for the files boot.S,portasm.S.

[Stefan O'Rear]

On Thu, Dec 1, 2016 at 9:36 PM, Raghav Hrishi
<kookaburr...@gmail.com> wrote:
> Do you suggest that make changes in the memory allocations that we have

> assigned ? I feel that there is some problem with the return command. I have
> changed 'eret' to 'mret' as I read that mret is essential. I made the
> changes for the files boot.S,portasm.S.

I'm afraid that if you want to make progress on this you're going to
need a solid working understanding of the RISC-V Privileged
Architecture draft 1.9.1 and probably also spike internals so that you
can run it under a debugger. If you don't know what mode that code
runs in, and I don't know what mode that code runs in, then none of us
can help. Actually I think the problem is somewhere else entirely.
You're going to need to spend a day or two single-stepping this to
find out exactly where and why it breaks. MRET was not the only
change in 1.9.

-s