Greetings. I am using the freedom-e-sdk to compile bare-metal applications for the gem5 simulator (it closely models HiFive Unmatched). In the simulator there is a plic that produces an interrupt (int_num = 26). Looking at the examples it’s not clear to me how to setup an interrupt handler. Could someone provide me with some example code on how to do this ? Any help is greatly appreciated.
Try the SiFive github page and search for ‘baremetal’ for examples.
@odxa20 By interrupt id=26 you mean GPIO18? You can also see a complete example code of a PLIC handler in the
start.s file of Demonstrating MTVEC
Thank you very much for the replies. The MTVEC example looks quite helpful. I will try to use it as baseline and report back. Concerning the interrupt id. In the gem5 system I am working on there are no GPIOS. I am using that interrupt id to signal that a custom accelerator finished its computation
@pds I just tested the MTVEC demonstration in gem5 and it worked! Is there a way to achieve the same functionality using the freedom-metal API to make the code more accessible to other people ?
Thanks @odxa20 As @dconn suggests, there is a freedom-metal example at plic-interrupts.c
A nice general discussion is in the SiFive Interrupt Cookbook though when it comes to PLIC the discussion is a bit abstract.
I like to think about RISC-V interrupt procedural handling flow with the following picture. Peripherals shown are for the FE310 SoC but the diagram is general for all types of core.
You might also find these forum conversations helpful:
What is PLIC interrupt source start and end in interrupt source mapping? and Use of external interrupt in vectored mode.
Thank you for the example code and similar threads. I had already found the plic-interrupts.c file but was confused as it was using the metal_switch API. How could I do the same thing but for a general external plic interrupt ?
A slightly more general PLIC example with the freedom metal API is in the plic-baremetal repo; a more extended version is in example-plic-baremetal-multicore.
I still prefer the simplicity, minimal latency, and memory overhead of assembly for interrupt handlers.
Note that clearing the external interrupt source is peripheral specific, in addition to the claim/complete process.