Hi,
I'm trying to factor the IRQ Table generation a bit, since the current way to write an IRQ Table plain sucks. This means
* gather all information before actually generating the table * gather information in a readable and adjustable way.
I juggled with the Arima Hdama irq table, since this one seems to work. (See attachment)
Currently I have a couple of defines that are hardcoded into the file. This should maybe be moved to the motherboard configuration files. (At least I would move them and the IRQ_SLOT_COUNT together)
#define IRQ_ROUTER_BUS 1 #define IRQ_ROUTER_DEVFN PCI_DEVFN(4,3) #define IRQ_ROUTER_VENDOR 0x1022 #define IRQ_ROUTER_DEVICE 0x746b #define AVAILABLE_IRQS 0xdef8
Then I substituted the longish irq table entries with a macro IRQ_SLOT which takes the following arguments: * slot number * bus,dev,fn * 4* irq link line id
Example: /* PCI Slot 1 */ IRQ_SLOT (1, 3,1,0, 2,3,4,1 ), /* Let Linux know about bus 1 */ IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),
If there are no objections, I am going to make this change in the code. Who else is having IRQ Table trouble here?
Stefan
On Tue, 20 Jan 2004, Stefan Reinauer wrote:
If there are no objections, I am going to make this change in the code. Who else is having IRQ Table trouble here?
looks fine.
Everyone is always having trouble. It may be best if we spend future effort on generating IRQ tables from MP tables, if that is possible.
ron
* ron minnich rminnich@lanl.gov [040120 16:59]:
looks fine.
Everyone is always having trouble. It may be best if we spend future effort on generating IRQ tables from MP tables, if that is possible.
I am not sure if our current mp tables know enough of the hardware to do so. Interrupts are often hardwired so there has to be knowledge in LinuxBIOS on which slot gets which interrupt.
The configuration files should contain this knowledge.
< Bridges > -- 1:n -- < slots > -- 1:n(m:n?) -- < irqs >
Reading the Linux kernel sources it seems that Linux _does_ expect the devices to have interrupts assigned already, which obviously LinuxBIOS does not do. This has to be "fixed" if LinuxBIOS shall be open to anybody not patching special kernels that do the right thing.
Is there any way to generate a decent mptable? The result from the mptable utility in the freebios 1 tree seems not to do it's best on AMD systems.
If we provide tables at all, can we maybe drop the irq table and only use the mptable?
Best regards, Stefan Reinauer
On Tue, 20 Jan 2004, Stefan Reinauer wrote:
Reading the Linux kernel sources it seems that Linux _does_ expect the devices to have interrupts assigned already, which obviously LinuxBIOS does not do. This has to be "fixed" if LinuxBIOS shall be open to anybody not patching special kernels that do the right thing.
no. In 2.4, in the right circumstances, the kernel can assign interrupts just fine.
If we provide tables at all, can we maybe drop the irq table and only use the mptable?
no, sadly the kernel needs an irq table for pci bus scanning.
ron
* ron minnich rminnich@lanl.gov [040121 07:35]:
If we provide tables at all, can we maybe drop the irq table and only use the mptable?
no, sadly the kernel needs an irq table for pci bus scanning.
good. things seem to work now. Except that the secondary bus of the 8151 gets set to 0, where it seems that in our case this should be 2 (the AGP device is visible on bus 2) Don't think this matters though
Stefan
On Thu, 2004-01-22 at 04:06, Stefan Reinauer wrote:
- ron minnich rminnich@lanl.gov [040121 07:35]:
If we provide tables at all, can we maybe drop the irq table and only use the mptable?
no, sadly the kernel needs an irq table for pci bus scanning.
good. things seem to work now. Except that the secondary bus of the 8151 gets set to 0, where it seems that in our case this should be 2 (the AGP device is visible on bus 2) Don't think this matters though
Stefan
Did you just dump the IRQ table from normal BIOS and put it in LinuxBIOS ?
That is the same problem we found here. The normal BIOS tries to make the secondary bus of 8151 as bus 0. It also tries to hide the bridge from IRQ and/or MP table.
The way we are configuring the PCI system is too different from what normal BIOS does on K8 systems. We can't just dump the table from BIOS and expect it to work anymore.
Ollie
* Li-Ta Lo ollie@lanl.gov [040122 17:22]:
good. things seem to work now. Except that the secondary bus of the 8151 gets set to 0, where it seems that in our case this should be 2 (the AGP device is visible on bus 2) Don't think this matters though
Did you just dump the IRQ table from normal BIOS and put it in LinuxBIOS ?
That is the same problem we found here. The normal BIOS tries to make the secondary bus of 8151 as bus 0. It also tries to hide the bridge from IRQ and/or MP table.
My assumption that the secondary bus is 0 on the 8151 comes from reading the SECONDARY_BUS register while creating the mptable.
This happens before the irq table is used for the first time.
Some pirq tables I've looked at showed the complete device tree of the machine, including the 2 cpus and all the bridges. We could probably generate a lot of this information automatically already. For getting the slots described right we need an additional slot command/tag in the config mechanism. Then we could just walk over all north/southbridges and generate both an irq table and an mptable from the device tree.
Stefan
Stefan Reinauer stepan@suse.de writes:
- Li-Ta Lo ollie@lanl.gov [040122 17:22]:
good. things seem to work now. Except that the secondary bus of the 8151 gets set to 0, where it seems that in our case this should be 2 (the AGP device is visible on bus 2) Don't think this matters though
Did you just dump the IRQ table from normal BIOS and put it in LinuxBIOS ?
That is the same problem we found here. The normal BIOS tries to make the secondary bus of 8151 as bus 0. It also tries to hide the bridge from IRQ and/or MP table.
My assumption that the secondary bus is 0 on the 8151 comes from reading the SECONDARY_BUS register while creating the mptable.
Hmm. That sounds like a bug.
This happens before the irq table is used for the first time.
Some pirq tables I've looked at showed the complete device tree of the machine, including the 2 cpus and all the bridges. We could probably generate a lot of this information automatically already. For getting the slots described right we need an additional slot command/tag in the config mechanism. Then we could just walk over all north/southbridges and generate both an irq table and an mptable from the device tree.
That is one of my informal requirements for a stable freebios 2.0 release. To be able to generate the mptable and irq tables from the device tree.
Eric
ron minnich rminnich@lanl.gov writes:
On Tue, 20 Jan 2004, Stefan Reinauer wrote:
Reading the Linux kernel sources it seems that Linux _does_ expect the devices to have interrupts assigned already, which obviously LinuxBIOS does not do. This has to be "fixed" if LinuxBIOS shall be open to anybody not patching special kernels that do the right thing.
no. In 2.4, in the right circumstances, the kernel can assign interrupts just fine.
However the statement is still true that it is desirable that we assign irqs to support non linux operating systems.
We should have enough information to do so when we can generate the irq tables from the device tree.
If we provide tables at all, can we maybe drop the irq table and only use the mptable?
no, sadly the kernel needs an irq table for pci bus scanning.
In particular when the kernel does not see a pci-pci bridge going to a pci bus, it will not scan it unless it sees it in pirq table. This is only true of the i386 kernel. The x86-64 kernel uses different logic to accomplish the same thing.
Regardless if we can our house it order it will be easy to provide kernels with what they need.
Eric
On 22 Jan 2004, Eric W. Biederman wrote:
no. In 2.4, in the right circumstances, the kernel can assign interrupts just fine.
However the statement is still true that it is desirable that we assign irqs to support non linux operating systems.
yes, that is why we've started plugging support in: we needed it for EPIA for Plan 9 ...
ron
ron minnich rminnich@lanl.gov writes:
On 22 Jan 2004, Eric W. Biederman wrote:
no. In 2.4, in the right circumstances, the kernel can assign interrupts just fine.
However the statement is still true that it is desirable that we assign irqs to support non linux operating systems.
yes, that is why we've started plugging support in: we needed it for EPIA for Plan 9 ...
And to be very clear the reason it is needed for the EPIA is that VIA is slightly out of spec. VIA chipsets instead of just providing a scratch irq register, actually interpret the value of that register for irq routing.
So while a general purpose solution should work in the EPIA case the via chipsets may still require special casing. Although hopefully we can abstract an irq router well enough we won't have to worry about it.
Eric
* Stefan Reinauer stepan@suse.de [040120 13:57]:
I'm trying to factor the IRQ Table generation a bit, since the current way to write an IRQ Table plain sucks. This means
- gather all information before actually generating the table
- gather information in a readable and adjustable way.
I juggled with the Arima Hdama irq table, since this one seems to work. (See attachment)
On my Solo I still don't get further. The pci cards irqs get routed fine to the interrupt pins, but those don't get any irq numbers.
Also, if I disable the amd8111 builtin ethernet card, the system hangs.
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
Hi,
I'm trying to factor the IRQ Table generation a bit, since the current way to write an IRQ Table plain sucks. This means
- gather all information before actually generating the table
- gather information in a readable and adjustable way.
I juggled with the Arima Hdama irq table, since this one seems to work. (See attachment)
Currently I have a couple of defines that are hardcoded into the file. This should maybe be moved to the motherboard configuration files. (At least I would move them and the IRQ_SLOT_COUNT together)
#define IRQ_ROUTER_BUS 1 #define IRQ_ROUTER_DEVFN PCI_DEVFN(4,3) #define IRQ_ROUTER_VENDOR 0x1022 #define IRQ_ROUTER_DEVICE 0x746b #define AVAILABLE_IRQS 0xdef8
Then I substituted the longish irq table entries with a macro IRQ_SLOT which takes the following arguments:
- slot number
- bus,dev,fn
- 4* irq link line id
Example: /* PCI Slot 1 */ IRQ_SLOT (1, 3,1,0, 2,3,4,1 ), /* Let Linux know about bus 1 */ IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),
If there are no objections, I am going to make this change in the code. Who else is having IRQ Table trouble here?
Sounds like a good small step. I object only on the grounds it does not go far enough. We should go at least as far as we have with mptable generation, so we can be isolated from bus renumbering. And preferably we should go all of the way to generating it from the device tree.
Eric
-
ebiederman＠lnxi.com -
Li-Ta Lo -
ron minnich -
Stefan Reinauer