On 12/22/20 10:23 AM, Mark Cave-Ayland wrote:
On 22/12/2020 16:16, Guenter Roeck wrote:
Hi,
commit 459ca8bfa41 ("pci: Assert irqnum is between 0 and bus->nirqs in
pci_bus_change_irq_level") added sanity checks to the interrupt number passed
to pci_bus_change_irq_level(). That makes sense, given that bus->irq_count
is indexed and sized by the number of interrupts.
However, as it turns out, the interrupt number passed to this function
is the _mapped_ interrupt number. The result in assertion failures for various
emulations.
That doesn't sound quite right. My understanding from the other boards I have
been working on is that they use the map_irq() functions recursively so that
the final set_irq() is on the physical pin, so it might just be that the
assert() is simply exposing an existing bug.
Examples (I don't know if there are others):
- ppc4xx_pci_map_irq() maps the interrupt number to "slot - 1". Obviously
that isn't a good thing to do for slot 0, and indeed results in an
assertion as soon as slot 0 is initialized (presumably that is the root
bridge). Changing the mapping to "slot" doesn't help because valid slots
are 0..4, and only four interrupts are allocated.
- pci_bonito_map_irq() changes the mapping all over the place. Whatever
it does, it returns numbers starting with 32 for slots 5..12. With
a total number of 32 interrupts, this again results in an assertion
failure.
ppc4xx_pci_map_irq() is definitely buggy. I just don't know what the
correct mapping should be. slot & 3, maybe ?
Yeah that doesn't look right. Certainly both the Mac PPC machines use ((pci_dev->devfn
>> 3)) & 3) plus the interrupt pin so I think you're right that this is missing an
& 3 here. Does adding this allow your image to boot?
Actually, it does not help. This does:
@@ -247,7 +247,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int
irq_num)
trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
- return slot - 1;
+ return slot ? slot - 1 : slot;
}
but I have no idea why.
I don't really have a good solution for pci_bonito_map_irq(). It may not
matter much - I have not been able to boot fuloong_2e since qemu v4.0,
and afaics that is the only platform using it. Maybe it is just completely
broken ?
It looks like you want this patchset posted last week:
20201216022513.89451-1-jiaxun.yang@flygoat.com/">https://patchew.org/QEMU/20201216022513.89451-1-jiaxun.yang@flygoat.com/
(specifically:
20201216022513.89451-1-jiaxun.yang@flygoat.com/20201216022513.89451-4-jiaxun.yang@flygoat.com/">https://patchew.org/QEMU/20201216022513.89451-1-jiaxun.yang@flygoat.com/20201216022513.89451-4-jiaxun.yang@flygoat.com/).
Zoltan was working on the VIA southbridge wiring at the start of the year and
provided me a test case that would boot Linux on the fulong2e machine, so at
that point in time it wasn't completely broken.
Those patches don't help for my tests. Problem is that I try to boot from ide
drive.
qemu-system-mips64el -M fulong2e \
-kernel vmlinux -no-reboot -m 256 -snapshot \
-drive file=rootfs.mipsel.ext3,format=raw,if=ide \
-vga none -nographic \
--append "root=/dev/sda console=ttyS0"
-serial stdio -monitor none
This works just fine with qemu v3.1. With qemu v5.2 (after applying the
fuloong patch series), I get:
VFS: Cannot open root device "sda" or unknown-block(0,0): error -6
This used to work up to qemu v3.1. Since qemu v4.0, there has been a variety
of failures. Common denominator is that the ide drive is no longer recognized,
presumably due to related changes in the via and/or pci code between v3.1
and v4.0.
Difference in log messages:
v3.1:
pci 0000:00:05.1: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
pci 0000:00:05.1: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:05.1: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0000:00:05.1: reg 0x1c: [mem 0x100000370-0x10000037f 64bit]
...
pata_via 0000:00:05.1: BMDMA: BAR4 is zero, falling back to PIO
ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
...
----
v5.2:
pci 0000:00:05.1: reg 0x10: [io 0x0000-0x0007]
pci 0000:00:05.1: reg 0x14: [io 0x0000-0x0003]
pci 0000:00:05.1: reg 0x18: [io 0x0000-0x0007]
pci 0000:00:05.1: reg 0x1c: [io 0x0000-0x0003]
pci 0000:00:05.1: reg 0x20: [io 0x0000-0x000f]
pci 0000:00:05.1: BAR 4: assigned [io 0x4440-0x444f]
...
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x4440 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x4448 irq 15
[and nothing else]