[lowrisc-dev] PCR Interrupts

Francesco Viggiano francesco.vgg at gmail.com
Wed Jul 27 18:07:46 BST 2016


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> 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> 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> wrote:
>>
>>> Hello Francesco,
>>>
>>> In the untether-v0.2 version, if you have connected an interrupt source
>>> to the 'interrupt' signal in 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> 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>
>>>> wrote:
>>>>
>>>>> On 21 July 2016 at 18:32, Wei Song <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