[LinuxBIOS] Building an irq table - Help

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,

[Marc Jones]

[e-mail] 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

Quoting Marc Jones :
> [e-mail] 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
>
> 0xDDDDFFFF, LNK, 00, GSI
>
> 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

[Corey Osgood]

[e-mail] wrote:
> Quoting Marc Jones :
> > [e-mail] 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
> >
> > 0xDDDDFFFF, LNK, 00, GSI
> >
> > 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,
Corey

[Uwe Hermann]

On Thu, Oct 18, 2007 at 11:01:59PM -0400, Corey Osgood wrote:
> 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.

I'm not sure either (and I'm not a lawyer of course), but I'd refraid
from distributing whole ACPI tables + AML code gathered via acpidump
(my guess is that the AML code is the bigger problem, as it's "code"
whereas the static tables are just a bunch of numbers/data items in
a simple list, more or less).

Not sure if it's a problem indeed, but we shouldn't take the risk if
we don't have to.

The alternative is to either have the _user_ use acpidump on his system
(and we provide a generic ACPI framework which can deal with acpidump
output, more on that later). This is similar to the VGA blob approach.

The other possibility is to construct a valid irq_table.c with the help
of the _PRT info (no need for ACPI if all you want is a working irq_table.c).

Or, you can try to fix up irq_table.c with the help of the method
Juergen described in http://linuxbios.org/Creating_Valid_IRQ_Tables,
where I'm pretty much 100% sure that there's _no_ legal problem
involved whatsoever.

Uwe.

[Carl-Daniel Hailfinger]

On 19.10.2007 05:01, Corey Osgood wrote:
> 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.

The problem is that the DSDT is copyrighted by the BIOS vendor, not the
board vendor. That means the copyright holder has a very strong interest
to enforce his copyright because he is a direct competitor of us.

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 19.10.2007 05:01, Corey Osgood wrote:
> > 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.
>
> The problem is that the DSDT is copyrighted by the BIOS vendor, not the
> board vendor. That means the copyright holder has a very strong interest
> to enforce his copyright because he is a direct competitor of us.

The same applies, and does not apply, for the pirq table and the
mptable. As long as you learn how the routing is wired, and do not cut
and paste any code, you are on the safe side of inter-operability.

Stefan

[Stefan Reinauer]

Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > On 19.10.2007 05:01, Corey Osgood wrote:
> > > 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.
> >
> > The problem is that the DSDT is copyrighted by the BIOS vendor, not the
> > board vendor. That means the copyright holder has a very strong interest
> > to enforce his copyright because he is a direct competitor of us.
>
> The same applies, and does not apply, for the pirq table and the
> mptable. As long as you learn how the routing is wired, and do not cut
> and paste any code, you are on the safe side of inter-operability.

For clarification: Copyright, unlike patents, do not prevent anyone from
re-inventing the wheel as long as you don't steal the wheel.

[Marc Jones]

[e-mail] wrote:
> Quoting Marc Jones :
> > [e-mail] 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,(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
> >
> > 0xDDDDFFFF, LNK, 00, GSI
> >
> > 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

The bitmap is means for every bit that is set can be routed as an IRQ. 
So, bit 10 and 11 set means that link can be programmed to IRQ 10 or 11. 
The bitmap would be 0x0c00.

0xded8 = 1101111011011000
          |          ||_IRQ3
          |          |__IRQ4
          |_IRQ15

Marc

Quoting Marc Jones :
> [e-mail] wrote:
> > Quoting Marc Jones :
> > > [e-mail] 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,(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
> > >
> > > 0xDDDDFFFF, LNK, 00, GSI
> > >
> > > 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
>
> The bitmap is means for every bit that is set can be routed as an IRQ.
> So, bit 10 and 11 set means that link can be programmed to IRQ 10 or
> 11. The bitmap would be 0x0c00.
>
> 0xded8 = 1101111011011000
>          |          ||_IRQ3
>          |          |__IRQ4
>          |_IRQ15
>
> Marc

Oh ok, that makes perfect sense. So it looks like in 0xded8 they  
pretty much made the range open to as many irqs available to PCI. What  
is the benifit of using such a large range? Just lazy coding if they  
are all the same (0xded8)?

Thanks - Joe

[ron minnich]

On 10/19/07, [e-mail]  wrote:
> >
>
> Oh ok, that makes perfect sense. So it looks like in 0xded8 they
> pretty much made the range open to as many irqs available to PCI. What
> is the benifit of using such a large range? Just lazy coding if they
> are all the same (0xded8)?

lazy coding and a lot of the vendors don't test/understand the IRQ tables.

ron