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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
