(chakravarthi) #1

Hello everyone, I have been working on RISC-V from past few months. Got stuck near the initialisation of CSRs.
I would like to know what CSRs are initialised during _init process, and also the delegation registers initial values.

thank you

(Thomas Hornschuh) #2

Without knowing the environment (e.g. processor core) you are using and the goals you have it is hard to say.

A minimal bare metal program which does not use interrupts is not required to initialize any csr at all.

To be able to handle traps (like illegal instruction faults) you should set mtvec to your trap handler.
If you want to use interrupts you need to set mstatus and mie.

If you want to use virtual memory, etc. it is a different story.
Besides the csrs you may also require to initalize other parts of the SoC like PLLs, caches, etc.

I think for the SiFive chips it is best to look at the board support package code in their SDKs. If you use another RISC-V implementation (e.g. Microsemi Mi-V, Puplino, PicoRV, etc.) you may look in their example/SDK code.

(chakravarthi) #3

Thank you Thomas Hornschuh for your reply. I am sorry for not mentioning details about my implementation in previous question.

I am trying to design a core with RV64IMA support first and boot linux. so, for booting linux we have to implement Machine, Supervisor and User modes. As we know OS runs in Supervisor mode and Machine mode is Firmware, if there is any trap it should be handled either by Machine or Supervisor mode. Let us suppose that they are handled by supervisor mode, for that STVEC CSR must contain trap vector base address. (For now let us consider Interrupts are also used.)

My questions

  1. Can all traps be handled by Supervisor mode ?
  2. How come we know the trap vector base address, should we take a look at linux _init code?
    If my understanding is wrong please correct me.

Thank you.

(Sean Halle) #4

Thanks for the response Thomas. We would like to turn on virtual memory in bare metal. The ISA tests do that, to test the TLB. Could you supply a few pointers about pulling that assembly level Virtual Memory support into bare metal C programs?