Good point. I did not know about ACPI. Ok, looking through the source, I don't see ACPI in the gx1 code. So I presume that this means that LinuxBIOS doesn't provide ACPI support in the case of the Geode.
Would I be able to test if Linux 2.6.10 is able to parse the normal BIOS' PIRQ table by booting linux with acpi=off? If it does work at that point, then I could assume that the area to be fixed would be the PIRQ table generation in LinuxBIOS. If not, then it'd be time to examine the kernel's pirq code.
I'm still somewhat confused though. At the point that LB calls the kernel, shoudn't LB have used the IRQ table values to set the PCI config space registers to write IRQ values to the PCI config registers and such? And if that were done, Linux would not need to parse a PIRQ table, yes?
Thanks.
--- Stefan Reinauer stepan@openbios.org wrote:
- ramesh bios ramesh_bios@yahoo.com [050301
08:19]:
That's odd. My understanding might be lacking.
I think the PIRQ table parser in 2.6.10 seems to
work
because it works when I use the normal BIOS.
Sure normal BIOS does not provide ACPI instead? In such case, PIRQ stays mostly untouched.
Stefan
Linuxbios mailing list Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
__________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
* ramesh bios ramesh_bios@yahoo.com [050301 12:22]:
Would I be able to test if Linux 2.6.10 is able to parse the normal BIOS' PIRQ table by booting linux with acpi=off? If it does work at that point, then I could assume that the area to be fixed would be the PIRQ table generation in LinuxBIOS. If not, then it'd be time to examine the kernel's pirq code.
Yes. Something along that line. For the one Geode system I had, I wrote the interrupt configuration myself, avoiding to fiddle with kernel pirq code (still needs a somewhat correct pirq table)
I'm still somewhat confused though. At the point that LB calls the kernel, shoudn't LB have used the IRQ table values to set the PCI config space registers to write IRQ values to the PCI config registers and such? And if that were done, Linux would not need to parse a PIRQ table, yes?
LinuxBIOS does not do that, it provides the tables and requires the OS to do so.
And if that were done, Linux would not need to parse a PIRQ table, yes?
LinuxBIOS does not do that, it provides the tables and requires the OS to do so.
I've found that Linux up to 2.6.9 (I haven't tested .10) Dosen't do this fully. With my 440bx chipset there are config registers in the northbridge that control which IRQ line each of the PCI PIRQ lines are routed to. Even with a proper PIRQ table these registers are not setup and I get the same error reported.
I have code in my final_mainboard_fixup() that sets these registers such that they match my table and then every thing works fine.
I suggest you diff the output of lspci -xxx for the northbridge between linubios and factory bios and resolve all the differences with the datasheet.
On Tue, 1 Mar 2005, Richard Smith wrote:
I've found that Linux up to 2.6.9 (I haven't tested .10) Dosen't do this fully. With my 440bx chipset there are config registers in the northbridge that control which IRQ line each of the PCI PIRQ lines are routed to. Even with a proper PIRQ table these registers are not setup and I get the same error reported.
that's whacky. The old linux did fine with 440bx. I never had to do anything but set up PIRQ tables.
I suggest you diff the output of lspci -xxx for the northbridge between linubios and factory bios and resolve all the differences with the datasheet.
on the geode 2.4.18 always worked, and if I patched linux for later linuxes, that worked fine too.
What a mess PIRQ got to be ....
ron
On Tue, 1 Mar 2005, ramesh bios wrote:
Would I be able to test if Linux 2.6.10 is able to parse the normal BIOS' PIRQ table by booting linux with acpi=off?
no, the problem is that the BIOSes we have seen in some cases just assign a bunch of IRQs, and ignore their own tables. Hence, the problem gets harder.
I'm still somewhat confused though. At the point that LB calls the kernel, shoudn't LB have used the IRQ table values to set the PCI config space registers to write IRQ values to the PCI config registers and such?
no, we have always let Linux do this because: - for a given version of linux, you really don't know what tables it will use, so it makes no sense to do a lot of work and then have linux repeat it - there are multiple options in some cases for which IRQ to use, and again, you want to let the OS figure that out
ron
-
ramesh bios -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer