[lowrisc-dev] PCR Interrupts

Wei Song ws327 at cam.ac.uk
Wed Jul 27 16:05:03 BST 2016


There are assembly instructions to handle CSRs, such as csrr, csrw, csrrw.
Also some macros are defined to read/write CSRs. Have a look of encoding.h.
However, the more important issue is, depending on the CSR address, some
CSRs are only accessible in privileged mode such as machine mode.
That is why some functions are defined in syscall to allow user mode
programs to access them.
The syscall definitions are in driver/syscall.c
Syscall use some assembly functions (asm_set_iobase0) to do the actual job.
These assembly functions are defined in crt.S. I must admit this is an
awful way to do but work.

It is then your own decision on how to do it in your programs.

Best regards,
Wei

On 27/07/2016 15:51, Francesco Viggiano wrote:
>
> Ok thank you so much for your explanation. How can CSR registers in
> PCR be access in code? I see that in boot.c example a syscall function
> is used to write to CSRs,  what about reading?
>
> Francesco
>
>
> On Wed, Jul 27, 2016, 09:06 Wei Song <ws327 at cam.ac.uk
> <mailto:ws327 at cam.ac.uk>> wrote:
>
>     Hello Francesco,
>
>     In the untether-v0.2 version, if you have connected an interrupt
>     source to the 'interrupt' signal in chip_top.sv
>     <http://chip_top.sv>, it is hooked to the Rocket-chip.
>     The interrupt enable and pending registers are mapped to the CSR
>     space. These are defined in uncore/src/scala/pcr.scala
>     Each Rocket core (up to 8) has its own interrupt pending (read
>     only) and interrupt enable CSRs.
>
>     The base CSR address is pint_map 0x7c0
>     For Rocket core i:
>     CSR address for interrupt enable: pint_map + i*2
>     CSR address for interrupt pending: pint_map + i*2 + 1
>
>     As for interrupt handler:
>     When an interrupt is outstanding (irq pin gets high), pc is
>     trapped into machine mode, label interrupt in mentry.S
>     Then around line 241, if it is a IRQ, pc jumps to io_irq_service()
>     defined in mtrap.c
>
>     Currently only UART interrupt is used. So there is no read to the
>     interrupt pending.
>     If multiple interrupt sources are enabled, this function should
>     first tell which is the interrupt source and handle accordingly.
>
>     Best regards,
>     Wei
>
>
>     On 26/07/2016 21:24, Francesco Viggiano wrote:
>>     Hi guys, 
>>
>>     As regards interrupts, I'm adding a new peripheral attached to
>>     interrupt line 3.   How can I register a new interrupt source in
>>     the int_en register and where do I have to write the interrupt
>>     service routine? I cannot find in the bbl where do you register
>>     uart and spi interrupts to be connected to irq0 and irq1
>>     respectively.
>>
>>     Thank you!
>>
>>     Francesco
>>
>>     On Fri, Jul 22, 2016 at 11:18 PM Francesco Viggiano
>>     <francesco.vgg at gmail.com <mailto:francesco.vgg at gmail.com>> wrote:
>>
>>         Thank you guys! I got it.
>>
>>         Also, Does this current untethered version support Linux
>>         kernel modules? I am trying to use modules with "insmod" but
>>         it states that relocation is not supported. Is there any way
>>         to install modules in this version?
>>
>>         Thank you, 
>>
>>         Francesco
>>
>>         On Thu, Jul 21, 2016 at 1:40 PM Alex Bradbury
>>         <asb at asbradbury.org <mailto:asb at asbradbury.org>> wrote:
>>
>>             On 21 July 2016 at 18:32, Wei Song <ws327 at cam.ac.uk
>>             <mailto:ws327 at cam.ac.uk>> wrote:
>>             > Hello Francesco,
>>             >
>>             > The interrupt sources are simply or-reduced and
>>             connected to the irq pin of
>>             > each core.
>>             > There is an enable register (per core in PCR) which can
>>             be used to disable
>>             > certain interrupt source.
>>             > If a core decide to enable a source and response, it
>>             can read the pending
>>             > register in pcr (if level triggered) or poll actual
>>             devices to find out the
>>             > outstanding interrupts.
>>             > If level-triggered, core needs to handle interrupt
>>             directly with the source
>>             > device until the device withdraw its interrupt.
>>             >
>>             > I would say it is better to use a level triggered
>>             interrupt.
>>             > Edge triggered interrupt may need special hardware
>>             treatment.
>>             >
>>             > We will add a proper interrupt controller in the next
>>             code release.
>>
>>             To clarify, this interrupt controller will be the PLIC
>>             described in
>>             the 1.9 draft privileged spec
>>             https://riscv.org/wp-content/uploads/2016/07/riscv-privileged-v1.9-1.pdf
>>
>>             The slides+video from Krste's talk at the 4th RISC-V
>>             Workshop last
>>             week will hopefully go online soon, which outlines the
>>             principles
>>             behind this interrupt controller. For now you'll have to
>>             make do with
>>             the spec and my notes
>>             (http://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/)
>>             from the presentation. Krste describes the concept of an
>>             interrupt
>>             "gateway" that abstracts away differences between edge vs
>>             level
>>             triggered interrupts as they enter the PLIC. This is
>>             described in
>>             section 7.4 of the 1.9 RISC-V privileged spec.
>>
>>             Best,
>>
>>             Alex
>>
>>         -- 
>>         | Francesco Viggiano,  Columbia University, Staff associate
>>         researcher at Computer Science Building |
>>         | Phone: +1 646-9829-535, Skype ID: francesco.vgg |
>>         | Department of Computer Science 1214 Amsterdam Avenue |
>>         | Columbia University Mail Code 0401 | New York, NY 10027-7003 |
>>
>>     -- 
>>     | Francesco Viggiano,  Columbia University, Staff associate
>>     researcher at Computer Science Building |
>>     | Phone: +1 646-9829-535, Skype ID: francesco.vgg |
>>     | Department of Computer Science 1214 Amsterdam Avenue |
>>     | Columbia University Mail Code 0401 | New York, NY 10027-7003 |
>
>
> -- 
> | Francesco Viggiano,  Columbia University, Staff associate researcher
> at Computer Science Building |
> | Phone: +1 646-9829-535, Skype ID: francesco.vgg |
> | Department of Computer Science 1214 Amsterdam Avenue |
> | Columbia University Mail Code 0401 | New York, NY 10027-7003 |




More information about the lowrisc-dev mailing list