Hi Mike,
On 10.11.20 19:22, Mike Banon wrote:
Thank you very much for your advice, dear Naresh, I will try matching the UEFI routing.
I wouldn't expect too much. If things are configurable in the chipset (they usually are these days) it's possible that coreboot configures them differently and then the tables have to differ too.
this old "getpir" utility may help you ;) You may have to run: coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677
What I already discovered: *) To activate the irq_tables.c / intel_irq_routing_table code, I need to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I don't see it having any visible effect on the IRQ routing: instead, maybe this intel_irq_routing_table is supposed to be a reflection of this routing?
I would only give these things a look if you are 200% sure that you need it. Basically no major OS has used these in two decades, hence most of it in coreboot is untested and broken. I wouldn't be surprised if there isn't a single case of correct PIRQ tables in the tree.
You should check what KolibriOS actually uses. If it's not ACPI there are these three options (that I know about):
* MP table * PIRQ tables * INT_LINE registers in each PCI device' configuration space
The latter is both exceptionally simple and fragile. It ignores that the OS could make any changes at runtime. The expected IRQ number for each PCI device is simply written into that register by the firmware. It's ignored by the hardware but can be read by the OS. Here's a simple example:
* Assuming there's a device PCI 03:00.0 triggering PCI INTA. * The chipset is configured to translate that to PIRQ_B. * PIRQ_B is configured to trigger IRQ 4. * Then coreboot would just write 4 into INT_LINE of 03:00.0.
The OS could then pick that 4 up and it would work as long as nothing changes the PIRQ configuration. As all the PIRQ information is lost, the OS can't optimize things; but KolibriOS probably wouldn't want to?
*) By adding to mainboard.c / mainboard_pirq_data structure these lines {NB_PCIE_PORT3_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.3 */ /* 0:04.00 / 2:00.00 - IRQ 3 */ {NB_PCIE_PORT4_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.4 */ /* 0:05.00 / 3:00.00 - IRQ 3 */ I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00 devices, which are behind the 0:04.00 and 0:05.00 bridges respectively. And this assignment is even visible by KolibriOS now! But I don't know if it's normal that a lot of devices are sharing the same IRQ 3 now, is it bad?
If sharing is bad depends on the type of devices. As long as they are all PCI devs, it should work (maybe not at maximum efficiency). But if, for instance, it's shared with a legacy UART port, that couldn't work (different mode of IRQ, level vs. edge triggered).
I'm not 100% sure, but it seems that with these lines you can control how an interrupt INTA (/B/C/D) message (PCIe always uses in-band messages) is interpreted by the chipset. It looks like you tell it INTA (the most used one) will trigger PIRQ_A, INTB PIRQ_B, etc. If it's really configurable (otherwise I don't see why there should be such a table), you could try to shuffle these around. e.g.
{ NB_PCIE_PORT4_DEVFN, { PIRQ_B, PIRQ_C, PIRQ_D, PIRQ_A } },
Hope that helps, Nico