Hello guys, I'm using the Unthetered version of the lowrisc-chip. Are the interrupt sources going to the PCR edge-sensitive or level-sensitive? Will the actual interrupt be sampled and reimain pending even if the signal goes down? Or it needs to stay high until the CPU resolves it? Thank you for your support, Francesco

On 21 July 2016 at 18:32, Wei Song <ws327(a)cam.ac.uk&gt; 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

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(a)gmail.com <mailto:francesco.vgg@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(a)asbradbury.org <mailto:asb@asbradbury.org>> wrote: On 21 July 2016 at 18:32, Wei Song <ws327(a)cam.ac.uk <mailto:ws327@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 |

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(a)cam.ac.uk <mailto:ws327@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(a)gmail.com <mailto:francesco.vgg@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(a)asbradbury.org <mailto:asb@asbradbury.org>> wrote: > > On 21 July 2016 at 18:32, Wei Song <ws327(a)cam.ac.uk > <mailto:ws327@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 |

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;

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(a)cam.ac.uk <mailto:ws327@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(a)cam.ac.uk > <mailto:ws327@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(a)gmail.com <mailto:francesco.vgg@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(a)asbradbury.org <mailto:asb@asbradbury.org>> wrote: >> >> On 21 July 2016 at 18:32, Wei Song <ws327(a)cam.ac.uk >> <mailto:ws327@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 |

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(a)cam.ac.uk <mailto:ws327@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(a)cam.ac.uk > <mailto:ws327@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(a)cam.ac.uk >> <mailto:ws327@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(a)gmail.com >>> <mailto:francesco.vgg@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(a)asbradbury.org <mailto:asb@asbradbury.org>> wrote: >>> >>> On 21 July 2016 at 18:32, Wei Song >>> <ws327(a)cam.ac.uk <mailto:ws327@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 |