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 <nic...@gmx.de> 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 _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org