v1: epia-m: irq_tables.c, mainboard.c

ron minnich rminnich at lanl.gov
Mon Dec 1 18:29:00 CET 2003


On Mon, 1 Dec 2003, Niki Waibel wrote:



> i think we need a new thread for the ``intel dual netwokcard problem on
> epia-m'' topic.
> 

OK, I'm now looking at this for real :)


> facts (correct me if i am wrong!):
>         * intel dual eth nic is not working with linuxbios (2003-10-24).
>         * it can be plugged into the pci slot (00:14.0) of the epia-m.
>         * the dual nic has a pci-to-pci bridge on the card.
>         * that bridge assignes pci bus 2 (0=internal, 1=vga/agp?)
>         * the 2 nics on the card assign: 02:04.0 and 02:05.0
>         * linuxbios detects the bus/bridge and also sees the 2 nic.
>       !!* linuxbios does not assign irqs to the nics.
>         * default (2003-10-24) linuxbios src/mainboard/via/epia-m/irq_tables.c:

ok so far. 

>                 {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},

That's 0:14.0, or Bus 0, devfn 0xa0. 

>                 {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},

Note that linuxbios and the standard bios agree. 


> 
>         * it does not help using the new irq_tables.c.

which makes sense as the one in there is already correct. My mistake. The 
issue is that the card you're using has a bridge on it. I've never dealt 
with this before.


>         * i had to modify src/mainboard/via/epia-m/mainboard.c in addition to get it running.

>           --> basically add: ``pci_assign_irqs(2, 0x4, dualenetaIrq);
> pci_assign_irqs(2, 0x5, dualenetbIrq);''
>           in addition i had to play with the irq lists.

eek. You know that this is exactly the wrong way to do this and why, I 
assume. But it works, so keep it for now. But this will never go into the 
CVS. 


> 
> questions:
>         * what do the strange numbers in my new irq_table.c mean?

doesn't matter, the old one was probably ok.

>         * if everything is hardcoded in mainboard.c -- what is irq_table.c for?

irq_table.c is for linux, it tells linux how the irqs are wired up. In an
ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd
and those OSes would do everything correctly. In our world, each of these
OSes get it wrong often enough that we have to now assign it directly. I 
had hoped to avoid IRQ assignment in linuxbios but it seems that we have 
no choice -- too many busted hardware/OS bits out there. 

>         * is it possible that all this is hardcoded in mainboard.c for
> epia/epia-m only,
>           but not for other boards?

yes. 

>           other boards use irq_table.c to assign interrupts?

yes. And, *most of the time*, it works fine.

>    
     * if you plug a card to the pci slot linuxbios seems to detect everything
>           (devices/bridges/devices behind bridges).
>           why cannot we say: ok there is irq 5, 10, 11 and 12. assign that 4 irqs
>           to all devices which were detected in the previous stage.
>           this must be the way the regular bios does it...

Yes. We need more complex irq management in linuxbios. Obviously linux
doesn't know what to do here either.

>         * when booting the epia-m with the std (award) bios and using the getpir
>           prg -> the resulting irq_table.c does not work either. is it
> 	just ignored
>           by the epia-m setup, or what is it actually for?

I don't know what the award bios is doing. It's clear that linux is not 
able to handle the interrupt assignmnet in this case, so linuxbios will 
have to do more. Oh well. Another thing to add.

ron




More information about the coreboot mailing list