On 06/03/2023 22:00, BALATON Zoltan wrote:
On Mon, 6 Mar 2023, Mark Cave-Ayland wrote:
On 06/03/2023 12:33, BALATON Zoltan wrote:
According to the PegasosII schematics the PCI interrupt lines are
connected to both the gpp pins of the Mv64361 north bridge and the
PINT pins of the VT8231 south bridge so guests can get interrupts from
either of these. So far we only had the MV64361 connections which
worked for on board devices but for additional PCI devices (such as
network or sound card added with -device) guest OSes expect interrupt
from the ISA IRQ 9 where the firmware routes these PCI interrupts in
VT8231 ISA bridge. After the previous patches we can now model this
and also remove the board specific connection from mv64361. Also
configure routing of these lines when using Virtual Open Firmware to
match board firmware for guests that expect this.
This fixes PCI interrupts on pegasos2 under Linux, MorphOS and AmigaOS.
Signed-off-by: BALATON Zoltan <bala...@eik.bme.hu>
Reviewed-by: Daniel Henrique Barboza <danielhb...@gmail.com>
Tested-by: Rene Engel <reneenge...@emailn.de>
---
hw/pci-host/mv64361.c | 4 ----
hw/ppc/pegasos2.c | 26 +++++++++++++++++++++++++-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/hw/pci-host/mv64361.c b/hw/pci-host/mv64361.c
index 298564f1f5..19e8031a3f 100644
--- a/hw/pci-host/mv64361.c
+++ b/hw/pci-host/mv64361.c
@@ -873,10 +873,6 @@ static void mv64361_realize(DeviceState *dev, Error **errp)
}
sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->cpu_irq);
qdev_init_gpio_in_named(dev, mv64361_gpp_irq, "gpp", 32);
- /* FIXME: PCI IRQ connections may be board specific */
- for (i = 0; i < PCI_NUM_PINS; i++) {
- s->pci[1].irq[i] = qdev_get_gpio_in_named(dev, "gpp", 12 + i);
- }
}
static void mv64361_reset(DeviceState *dev)
diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c
index b0ada9c963..ded5dc2dc9 100644
--- a/hw/ppc/pegasos2.c
+++ b/hw/ppc/pegasos2.c
@@ -73,6 +73,8 @@ struct Pegasos2MachineState {
MachineState parent_obj;
PowerPCCPU *cpu;
DeviceState *mv;
+ qemu_irq mv_pirq[PCI_NUM_PINS];
+ qemu_irq via_pirq[PCI_NUM_PINS];
Vof *vof;
void *fdt_blob;
uint64_t kernel_addr;
@@ -95,6 +97,15 @@ static void pegasos2_cpu_reset(void *opaque)
}
}
+static void pegasos2_pci_irq(void *opaque, int n, int level)
+{
+ Pegasos2MachineState *pm = opaque;
+
+ /* PCI interrupt lines are connected to both MV64361 and VT8231 */
+ qemu_set_irq(pm->mv_pirq[n], level);
+ qemu_set_irq(pm->via_pirq[n], level);
+}
+
Can you explain a bit more about how the PCI interrupt lines are connected to both
the MV64361 and VT8231? The reason for asking is that I see a similar
I think I already did that in previous replies but I try again. In pagasosII
schematics at https://www.powerdeveloper.org/platforms/pegasos/schematics
Sheet 2 Marvell System Controller shows PINTA-D are connected to MV64361 MPP12-15
pins that are also called GPP in the docs (I think these are referred to as either
Multi Purpose or General Purpose Pins).
Sheet 18 VIA VT8231 Southbridge shows INTR_A-D connected to VT8231 PINTA-D pins,
which are connected to INTA-D on sheet 13 PCI Top Level. Sheet 1 Top Level Pegasos
shows that Sheet 13 INTA-D are connected to Sheet 2 PINTA-D.
pattern in the bonito board, but there I can't see how those lines would be used
because they can also raise a CPU interrupt, yet it is a different one compared to
the 8259.
Both the MV64361 and VT8231 have interrupt mask registers which allow the guest to
choose where it wants an interrupt from. I guess different guests could use one or
the other, unlikely they would use both but they could even do that if they wanted. I
guess in bonito it's also maskable so the guest could set up irqs by programing the
apprpriate north and south bridge registers. A guest which has ISA drivers (probably
most) may likely want to route them to ISA IRQs in the VIA chip. Maybe this strange
behaviour has to do with Windows compatibility and standards back then which never
really took off like CHRP for PP
Given that we know from Bernhard's tests that the fuloong2e board works with
pci_bus_irqs() included in via_isa_realize() which overwrites the bonito
equivalent, I'm wondering if the mv_pirq array is actually needed at all and
whether it may just be a debugging aid? Certainly it makes things simpler to just
route everything to the VIA device.
In any case calling pci_bus_irqs in the VIA device would be wrong and connections
Why? In general the PCI bus should be managed completely internally and not exposed
to the board. This should certainly be the case for the VIA chipsets which can be
used across multiple QEMU machines.
should be made here by the board as that correctly models the hardware separating
components and allows different boards to use the chip model in the future. I
remember that I've implemenred connections to MV64361 for something but I don't
remember which guest so as this already works and models what the schematics say I
see no reason not to have it or remove it.
That doesn't really help much I'm afraid - are the extra pirq lines required or not?
If so, which guest OS are they being used for? This information should be included in
the commit message and a code comment, as if you don't document things like this you
risk someone attempting a tidy-up refactoring which will break your guest OS.
ATB,
Mark.
