Re: [coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Hi Nico, thank you very much for your kind help, it really helped to
advance! Please could you answer a small question:

While cleaning up some code I noticed there are Misc,Misc0,Misc1,Misc2
interrupts - with the following "magic" values respectively:

mainboard_picr_data:
[0x08] = 0x5A,0xF1,0x00,0x00,
mainboard_intr_data:
[0x08] = 0x00,0x00,0x00,0x00,

I tried replacing all these values by 0x1F ("unused") : the _intr_data
0x1F values got reverted to 0x00 during the boot time, while the
_picr_data 0x1F values stayed - but caused a SeaBIOS to hang while
booting (so I had to unbrick a laptop). Do you have any guess: from
where these 0x5A,0xF1,0x00,0x00 values for Misc interrupts come from,
and why are they essential for a SeaBIOS to work? Bolton FCH BIOS Dev
Guide doesn't tell anything about them, just mentions their offsets.

Best regards,
Mike

On Wed, Nov 11, 2020 at 2:43 AM Nico Huber <[e-mail]> wrote:
> 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