[lowrisc-dev] PCR Interrupts

Wei Song ws327 at cam.ac.uk
Thu Jul 28 15:47:32 BST 2016


Configure string or something similar will be used to standardize
interrupts in the future.
So it is likely that no matter what to do to make it work with the
untether-v0.2, significant changes are needed for future releases.
I would say using whatever easiest way to do it, if it is also
reasonable maintainable.

I do not think I have enough knowledge to say which way is the best.

-Wei

On 27/07/2016 18:07, Francesco Viggiano wrote:
>
> Perfect thank you! So if I have to add a new interrupt source, and let
> the CPU running Linux to be sensible to it,  where do you suggest it
> would be more convenient to put write_csr(0x7c0, 0x9)? for example to
> enable source 0 and 3. Do I need to add a new device in Linux (if so, 
> how? )  and add a new case statement in mtrap.c or I can handle the
> interrupt directly in io_irq_service()?
>
>
> On Wed, Jul 27, 2016, 12:51 Wei Song <ws327 at cam.ac.uk
> <mailto:ws327 at cam.ac.uk>> wrote:
>
>     Indeed it is difficult to find. It costs my 15 minutes to find it
>     out myself.
>     So only the Linux kernel needs to to use UART's interrupt.
>     It is enabled in bbl/mtrap.c
>
>>     case HTIF_CMD_READ: /* uart read */
>>
>>     {
>>
>>     write_csr(0x7c0, 0x01); /* enable irq0 */
>>
>>
>>     // store the message in request queue
>>
>>     m->sbi_private_data = (uintptr_t)HLS()->device_request_queue_head;
>>
>
>     Here write_csr enables the UART interrupt.
>
>
>     -Wei
>
>
>     On 27/07/2016 17:20, Francesco Viggiano wrote:
>>     Ok, So in PCR, reg_int_en is set to 0 by default at reset; I
>>     cannot find in the bbl code, where do you enable Uart interrupt
>>     to be attached to interrupt source 0. If reg_int_en is 0 it means
>>     that the CPU is not sensible to any interrupts source, am I right?
>>
>>     On Wed, Jul 27, 2016 at 11:05 AM Wei Song <ws327 at cam.ac.uk
>>     <mailto:ws327 at cam.ac.uk>> wrote:
>>
>>         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 |
>>
>>
>>     -- 
>>     | 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