[libre-riscv-dev] how do we test external interrupts?

[libre-riscv-dev] how do we test external interrupts?

[Luke Kenneth Casson Leighton]

i've started on the XICS controller, and have converted both the ICS and
ICP.  a simple unit test on XICS-ICS shows it to be functional.

however we are hampered in several ways:

1) there does not appear to exist an actual accessible specification.

2) the only implementations are source code (linux kernel, qemu)

3) nobody else has written unit tests

4) given that XICS is involved in *external* interrupts, how do we even
*begin* to write a unit test that runs under e.g. qemu and the simulator,
here??

so i'd like to open up the discussion to develop a strategy here.

my feeling is that we may have to create a simulated peripheral (an
interrupt driven 16550 UART) in ISACaller which would allow exploration,
here.

thoughts welcome.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] how do we test external interrupts?

[Samuel Falvo II]

I might be stating the obvious; but, according to
https://www.kernel.org/doc/html/latest/virt/kvm/devices/xive.html, it
looks like XICS is a POWER7- / POWER8-related specification.
Wikipedia indicates POWER7 was released around 2010-ish.  Maybe
finding specs dated about that time would be a good place to look?  (I
tried but wasn't successful.)

On Tue, Jul 28, 2020 at 6:31 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> i've started on the XICS controller, and have converted both the ICS and
> ICP.  a simple unit test on XICS-ICS shows it to be functional.
>
> however we are hampered in several ways:
>
> 1) there does not appear to exist an actual accessible specification.
>
> 2) the only implementations are source code (linux kernel, qemu)
>
> 3) nobody else has written unit tests
>
> 4) given that XICS is involved in *external* interrupts, how do we even
> *begin* to write a unit test that runs under e.g. qemu and the simulator,
> here??
>
> so i'd like to open up the discussion to develop a strategy here.
>
> my feeling is that we may have to create a simulated peripheral (an
> interrupt driven 16550 UART) in ISACaller which would allow exploration,
> here.
>
> thoughts welcome.
>
> l.
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev



-- 
Samuel A. Falvo II

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] how do we test external interrupts?

[Luke Kenneth Casson Leighton]

On Tue, Jul 28, 2020 at 3:55 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:
>
> I might be stating the obvious; but, according to
> https://www.kernel.org/doc/html/latest/virt/kvm/devices/xive.html, it
> looks like XICS is a POWER7- / POWER8-related specification.
> Wikipedia indicates POWER7 was released around 2010-ish.  Maybe
> finding specs dated about that time would be a good place to look?  (I
> tried but wasn't successful.)

yeah i've reviewed v2.07B which was POWER8 and there's nothing in
that, either.  according to this:
https://github.com/qemu/qemu/blob/master/hw/intc/xics.c

the *actual* name is "Logical Partition" (LPAR) although where on
earth the relationship is with XICS, is completely unclear, and
reading the Chapter on LPAR Control (p927 v3.0B) gives nothing
obvious.  searching for keywords "CPPR", "MFFR" also give nothing.

if we are deploying reverse-engineering and pattern-matching, this
looks very similar to microwatt xics.vhdl:
https://github.com/qemu/qemu/blob/master/hw/intc/xics_pnv.c

at least the memory set/get looks familiar, where qemu xics.c looks
more like it is more qemu-internals / qemu-plumbing

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] how do we test external interrupts?

[Samuel Falvo II]

On Tue, Jul 28, 2020 at 9:15 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> the *actual* name is "Logical Partition" (LPAR) although where on

I saw a reference to LoPAR in my searches, which appeared to be
something different from LPAR.  I didn't research it further, though.

-- 
Samuel A. Falvo II

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] how do we test external interrupts?

[Jacob Lifshay]

I found what looks like the reference source:
in
https://github.com/torvalds/linux/blob/ab02b61f24c76b1659086fcc8b00cbeeb6e95ac7/Documentation/virt/kvm/devices/xics.rst
> This device emulates the XICS (eXternal Interrupt Controller
Specification) defined in PAPR.

https://en.wikipedia.org/wiki/Power_Architecture_Platform_Reference

https://github.com/OpenPOWERFoundation/Linux-Architecture-Reference

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] how do we test external interrupts?

[Luke Kenneth Casson Leighton]

On Tuesday, July 28, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> I found what looks like the reference source:
> in
> https://github.com/torvalds/linux/blob/ab02b61f24c76b1659086fcc8b00cb
> eeb6e95ac7/Documentation/virt/kvm/devices/xics.rst
> > 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".

what's needed:

* 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
interrupts
https://github.com/antonblanchard/microwatt/blob/master/hello_world/head.S

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 :)

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev