On 22/12/2020 21:23, Guenter Roeck wrote:
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.
That's interesting. I had a look at bamboo.dts in Linux and the interrupt-map
property suggests there are 4 fixed PCI slots available 1 to 4, so it shouldn't be
possible for slot 0 to generate an IRQ as nothing can be plugged there.
Can you share your reproducer? Feel free to send me links off-list if you
prefer.
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:
https://patchew.org/QEMU/20201216022513.89451-1-jiaxun.y...@flygoat.com/
(specifically:
https://patchew.org/QEMU/20201216022513.89451-1-jiaxun.y...@flygoat.com/20201216022513.89451-4-jiaxun.y...@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]
Again, can you share the files that you are using here? I think it's worth adding
Jiaxun Yang to this thread since the original cover letter at
https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04293.html states that this
latest series allows the Debian installer to boot.
ATB,
Mark.
