[LinuxBIOS] Building an irq table - Help

Corey Osgood corey.osgood at gmail.com
Fri Oct 19 05:01:59 CEST 2007

joe at smittys.pointclark.net wrote:
> Quoting Marc Jones <marc.jones at amd.com>:
>> joe at smittys.pointclark.net wrote:
>>> Ok I am a little confused on how to tell what devices are what in 
>>> irc_tablec.c
>>> How do I tell?? Also where does the value for the "bitmap" come from?
>>> Thanks for your help - Joe
>>> /* bus,     dev|fn,
>>> {0x01,(0x08<<3)|0x0,
>>> {0x00,(0x1f<<3)|0x0,
>>> {0x00,(0x1d<<3)|0x0,
>>> {0x00,(0x00<<3)|0x0,
>>> {0x00,(0x01<<3)|0x0,
>>> {0x01,(0x00<<3)|0x0,
>>> {0x01,(0x01<<3)|0x0,
>>> {0x01,(0x02<<3)|0x0,
>>> {0x01,(0x09<<3)|0x0,
>>> {0x01,(0x06<<3)|0x0,
>>> {0x01,(0x07<<3)|0x0,
>>> {0x00,(0x02<<3)|0x0,
>> Joe,
>> There is some good information here:
>> http://linuxbios.org/index.php/Creating_Valid_IRQ_Tables
>> http://www.microsoft.com/whdc/archive/pciirq.mspx
>> Your bus/dv/fun should match the devices found when you do an lspci.
>> The value for the bitmap is what IRQs are available on that INT#.
>> Theses are typically 10 and/or 11 but could be any shareable IRQ.
>> Marc
>> DDDD is PCI DEV, FFFF is function, LNK is PCI link - so LNKA B etc...
>> Next parameter is 00 if you do not support legacy PIC routing at all.
>> Last parameter is global interrupt NR.
>> Hope it helps,
>> Rudolf
> Thanks for your help Marc and Rudolf. I have been looking through most
> of the other irq_tables.c from different mainboards and it seems like
> on most of them the "fn" is 0x0 (like above). Is this a bug in
> getpir?? So do I need to manually change these to the correct functions?
> I understand where the "link" comes from. These are set in the LPC
> Bridge registers, but where does the value for the "bitmap" come from?
> Mine eithor say 0xded8 or 0x0000?? The 0x0000 means it is not routed
> right? But I don't get where the 0xded8 comes from?
> I just attached my irq_tables.c created from getpir so you can see
> what I mean.
> Thanks - Joe

I would mark those irq tables as broken and use acpi routing. You can
dump the factory acpi tables using acpidump (or cat /proc/acpi/dsdt >
somefile), then decompile them with iasl. Once you do that, you can look
through them for "(_PRT)", which should be the routing table. At that
point, if the tables are simple enough, you can just pull those out, or
if they're deeply integrated you can use the entire dsdt. Note that
there may be some legal issues with redistribution of acpi tables,
although the linux acpi project (on sourceforge) distributes them
regularly, so I'm not sure where the problem lies.

Good luck,

More information about the coreboot mailing list