[libre-riscv-dev] how do we test external interrupts?
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Jul 28 19:20:58 BST 2020
On Tuesday, July 28, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:
> I found what looks like the reference source:
> > This device emulates the XICS (eXternal Interrupt Controller
> Specification) defined in PAPR.
i glanced through that. the definitions there are for the format of the
linux kernel ioctls (etc) and they happen to *contain* the same information
as is read from the hardware registers (in the case of microwatt, over a
wishbone bus), and therefore they must *be* reading the memory locations
associated with each XICS register
it's just that it's damn hard to interpret because the linux kernel is
written as a re-entrant FSM.
throwing a full-on linux kernel at the HDL is one way to test this, however
it would be slow and also cumbersome to debug.
i'd really like to brainstorm on how to do a piece-by-piece set of small
tests, so that by the time we actually get to run a linux kernel we have a
high degree of confidence that it would "just work".
* the core needs an incoming "interrupt notifier" wire (coming from XICS
presentation layer) in microwatt this is ext_irq_in
* the external interrupt wire in the core needs to trigger the PC to jump
to 0x500 (microwatt execute1.vhdl ext_irq_in goes high)
* a mini interrupt handler (at address 0x500) that then starts looking at
the XICS registers (via the wishbone bus) and "handles" it
* an actual peripheral of some kind which is connected to one of the XICS
"source" irq interrupt bits that generates the interrupt in the first place
this bundle of five bits of HDL which will also need an appropriate
wishbone arbiter capable of dealing with 64/32 bit integration *and* some
software is about the minimum i can think of (!)
oh and also if we want to run the sane binary under ISACaller it needs
implementing like in qemu or dolphin!
which is quite ridiculous but there you go :v
looking at the microwatt helloworld example i don't think it's set up for
the 0x500 handler is a stub, there: i believe it goes into a 100% cpu
polling loop (see lib/console.c as well as hello_world.c)
this seems like a lot more work than formerly anticipated. however
throwing the linux kernel at the core and hoping does not inspire me with
deep feelings of joy :)
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the libre-riscv-dev