Re: Geode GX1 and IRQ tables
On Wed, Mar 09, 2005 at 05:08:20PM -0800, ramesh bios wrote: Yes, I was, or actually, am doubtful as well. I would have thought, for sure, you can turn off the cs5530a's claim of reads on that address block. But so far I can't find any way to do that, and it doesn't seem like anyone else has either. Perhaps setting the ROM interface to subtractive decoding will help? F0 Index 5Bh, Decode Control Register 2, Bit 5 BIOS ROM Positive Decode: Selects PCI positive or subtractive decoding for accesses to the configured ROM space. 0 = Subtractive; 1 = Positive. ROM configuration is at F0 Index 52h[2:0]. It resets to 1. (Page 94 in the data sheet.) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Oooh, looks interesting. I did not actually know what subtractive decoding is. Now I do. After talking to the local PCI guy, it means that the cs5530 will only claim the transaction if it doesn't see anyone else assert devsel# for some number of cycles. I will try this out soon. Thanks very much Peter. --- Peter Stuge [EMAIL PROTECTED] wrote: On Wed, Mar 09, 2005 at 05:08:20PM -0800, ramesh bios wrote: Yes, I was, or actually, am doubtful as well. I would have thought, for sure, you can turn off the cs5530a's claim of reads on that address block. But so far I can't find any way to do that, and it doesn't seem like anyone else has either. Perhaps setting the ROM interface to subtractive decoding will help? F0 Index 5Bh, Decode Control Register 2, Bit 5 BIOS ROM Positive Decode: Selects PCI positive or subtractive decoding for accesses to the configured ROM space. 0 = Subtractive; 1 = Positive. ROM configuration is at F0 Index 52h[2:0]. It resets to 1. (Page 94 in the data sheet.) //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Thu, Mar 10, 2005 at 03:01:56PM -0800, ramesh bios wrote: Oooh, looks interesting. I did not actually know what subtractive decoding is. Now I do. After talking to the local PCI guy, it means that the cs5530 will only claim the transaction if it doesn't see anyone else assert devsel# for some number of cycles. I will try this out soon. Thanks very much Peter. Welcome. If it doesn't work out, I guess the ROM size select could be (ab)used for some trickery if the location of the tables can be controlled. I.e. make sure it's below the top 64kb of ROM and use region size to switch between RAM and ROM. Hope the decode works out though, it's a lot cleaner. //Peter ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Tue, 8 Mar 2005, ramesh bios wrote: So what do you guys think I should do? Do you agree with my assessment above? The easiest thing to do would be to add a linux kernel boot parameter that'll allow LinuxBIOS to tell filo to tell the kernel exactly where in sdram the uncompressed PIRQ table is. yes, but then you have to keep maintaining your patch. I think I can do that. Alternately, since we know that Fh is the start of the flash, could we just reserve that small section of flash for storing an uncompressed PIRQ table and leave everything else as is. yes, but you're going to have to figure out how to do that :-) I think the simplest is CONFIG_COMPRESS=0, and just don't worry about it. LinuxBIOS fits, right? Then don't worry about it. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Looking at Stefan's /dev/bios code I see the use of 6 to enable write access to the flash. But I don't see the ability to disable the CS5530A's claim of the read cycle. So no way to map F elsewhere. I'm kind of doubtful on this. ROM shadowing has been part of chipsets for a long time and it seems really odd that they would just leave it out. Do you have the factory bios for the board? If so fire it up and make dd read from the f area and then watch the chip select on the bios chip to see if its asserted. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Yes, I was, or actually, am doubtful as well. I would have thought, for sure, you can turn off the cs5530a's claim of reads on that address block. But so far I can't find any way to do that, and it doesn't seem like anyone else has either. As for watching the chip select line, I'd love to do that but I don't have a logic analyzer or probes. I guess I could do it with an LED and a sharpened wire but I'd rather not risk damage to my board. :-) --- Richard Smith [EMAIL PROTECTED] wrote: Looking at Stefan's /dev/bios code I see the use of 6 to enable write access to the flash. But I don't see the ability to disable the CS5530A's claim of the read cycle. So no way to map F elsewhere. I'm kind of doubtful on this. ROM shadowing has been part of chipsets for a long time and it seems really odd that they would just leave it out. Do you have the factory bios for the board? If so fire it up and make dd read from the f area and then watch the chip select on the bios chip to see if its asserted. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Wed, 9 Mar 2005 17:08:20 -0800 (PST), ramesh bios [EMAIL PROTECTED] wrote: As for watching the chip select line, I'd love to do that but I don't have a logic analyzer or probes. I guess I could do it with an LED and a sharpened wire but I'd rather not risk damage to my board. :-) Oh. for some reason I thought you had a scope. You couldn't do it with an LED anyway the signal is too fast (you would never see it) and it doubtful that the chip select line would be able to source enough current to light and LED anyway. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
After reading Stefan's mention of F0 index 52h in the CS5530A, I think I'm begining to understand the problem. Currently, Fh is mapped to flash. This is because at reset, the CS5530A decodes that address block and claims those cycles, generating an ISA bus memory cycle specifically. I think the cs5530a only claims read cycles. So I think what I need to do is to do the copy to Fh like normal in copy_pirq_routing_table. Then, before verify_copy_pirq..., I need to tell the CS5530A to no longer claim read cycles for that address block. But... that might not be possible. Looking at Stefan's /dev/bios code I see the use of 6 to enable write access to the flash. But I don't see the ability to disable the CS5530A's claim of the read cycle. So no way to map F elsewhere. So in summary, I think there is no way to tell the gx1+cs5530a combo that Fh should be mapped to sdram. Since that can't be done, then it would require that the PIRQ table be stored uncompressed somewhere in the F-10 adress range. And that's what happens when building with CONFIG_COMPRESS=0 which does work of course since eventually the kernel finds it somewhere within the address range using the $PIRQ signature. But that feels dirty to me. So what do you guys think I should do? Do you agree with my assessment above? The easiest thing to do would be to add a linux kernel boot parameter that'll allow LinuxBIOS to tell filo to tell the kernel exactly where in sdram the uncompressed PIRQ table is. I think I can do that. Alternately, since we know that Fh is the start of the flash, could we just reserve that small section of flash for storing an uncompressed PIRQ table and leave everything else as is. I like the feel of that except I don't really now how all the linkage and addressing is assigned. Please let me know what you think. Thanks, Ramesh --- Ronald G. Minnich rminnich@lanl.gov wrote: On Fri, 4 Mar 2005, Ronald G. Minnich wrote: On Thu, 3 Mar 2005, ramesh bios wrote: Ok, so I tried this specific sequence and it failed. making region read/write nope. you need to make it write-only, arg, I'm not thinking, we are running out of high memory and then RAM. So making it read/write should have worked. Blash. Dump the memory at 0xf BEFORE and AFTER you copy the PIRQ. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Thu, 3 Mar 2005, ramesh bios wrote: Ok, so I tried this specific sequence and it failed. making region read/write nope. you need to make it write-only, Verifing priq routing tables copy at 0xf...failed, then copy The make it read-write. Could it be that f is mapped to the flash? yes, it's supposed to be! ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Fri, 4 Mar 2005, Ronald G. Minnich wrote: On Thu, 3 Mar 2005, ramesh bios wrote: Ok, so I tried this specific sequence and it failed. making region read/write nope. you need to make it write-only, arg, I'm not thinking, we are running out of high memory and then RAM. So making it read/write should have worked. Blash. Dump the memory at 0xf BEFORE and AFTER you copy the PIRQ. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Ok, so I tried this specific sequence and it failed. making region read/write done making region read/write Verifing priq routing tables copy at 0xf...failed, f=b0 while 87c0=24 Could it be that f is mapped to the flash? I'm trying to figure out whether that is technically possible for a gx1? Could the hardware somehow have a control that maps the 2Mbit flash to that block? Thanks. --- ramesh bios [EMAIL PROTECTED] wrote: Ok, so I think this means I should: 1. Enable writes for Fh thru F3FFFh (in gx_setup.inc) using BC_XMAP_3 2. Copy the pirq table to F as in pirq_routing.c:copy_pirq_routing_table 3. Enable read and writes for Fh thru F3FFFh in pirq_routing.c:verify_copy_pirq_routing_table using BC_XMAP_3 I'll give this a shot when I get some time and see how it goes. Thanks. --- Ronald G. Minnich rminnich@lanl.gov wrote: for shadow ram, you need to enable writes to go to ram. Later on, when you are done with a region, you need to enable reads. So the way you do this: figure out which one is for 0xf. Enable writes (2). At the end of the process, you need to set (3) for the area. And, somebody will have to explain how this fits in with the new stuff, as I have not looked at shadow ram setup at all in V2! ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Ramesh, At 04:02 02/03/2005, ramesh bios wrote: 1. Shadow RAM I guess I would need to find a way to tell the northbridge to enable shadow RAM for some range around f. I looked through the CS5530A datasheet and see shadow registers but no mention of shadowing RAM. Nor in the GX1 datasheet either. I'm looking for some register in either the GX1 or the CS5530A that would enable this. I am looking for some register that would enable me to remap the C-F address range to somewhere in sdram. Is that the right thing to be looking for? I think you may need to look at your settings for the BC_XMAP_2 and BC_XMAP_3 registers on the GX1 - these control read and write access to the BIOS shadow ram regions. 2. Uncompressed payload I'm not sure I understand what this means. Right now, my payload is filo. In the build, I see: dd conv=sync bs=196608 if=/bios/filo-0.4.2/filo.elf of=payload.block cat payload.block romimage Oh, I guess you must mean this stuff: objcopy -O binary linuxbios_c linuxbios_payload.bin ./nrv2b e linuxbios_payload.bin linuxbios_payload.nrv2b So I guess there is some kind of compression going on there. Not sure if you're using Linuxbios V1 or V2 but in V1 there is an option in your build config file to turn off compression - you probably need something like: option CONFIG_COMPRESS=0 If it's V2 then no doubt there is an equivalent there too. Which method would be the right thing to do? I'll look at the shadow ram thing first then. Thanks. Nope this helps Ian --- Ronald G. Minnich rminnich@lanl.gov wrote: On Tue, 1 Mar 2005, ramesh bios wrote: Strike that. The issue is somewhere with copy_pirq_routing_table. IE: why does the copy to f fail. I had assumed that the 500 address was an alternate location that the table was copied to. So now, I'm looking at that f000 failure. the copy to f fails because shadow ram is not set up. You can fix this one of two ways. One is to figure out how to enable shadow ram. The second is to make the payload uncompressed. The copy will still fail but linux will find the PIRQ table anyway. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Hi, Thanks for the hint. I see the BC_XMAP registers touched in nsc/gx1/gx_setup.inc. .long BC_XMAP_1, 0x60 .long BC_XMAP_2, 0 .long BC_XMAP_3, 0 And from the gx1 spec: --- GX_BASE+800Ch-800Fh BC_XMAP_3 Register (R/W) Default Value = h 19:16 F0 F0 Region: Region control field for address range Fh to F3FFFh. Bit Position: Function 3 PCI Accessible: The PCI slave can access this memory if this bit is set high and if the appropriate Read or Write Enable bit is also set high. 2 Cache Enable1: Caching this region of memory is inhibited if this bit is cleared. 1 Write Enable1: Write operations to this region of memory are allowed if this bit is set high. If this bit is cleared, then write operations in this region are directed to the PCI master. 0 Read Enable: Read operations to this region of memory are allowed if this bit is set high. If this bit is cleared then read operations in this region are directed to the PCI master. --- So 3 looks like the right value to set to enable read and write. So at first I tried with 0x just to see what would happen if I made all those regions read/write. (I'm still not sure how the gx1 processor knows what part of SDRAM those regions are mapped to.) In any case, that results in a hang immediately after boot. You see just: LinuxBIOS starting... Meaning, you don't see even raminit occur. Then I tried just 0x0003 and that had the same effect. I then tried moving the 3 across one by one to see if any would avoid the hang. But nope, a 3 in any of those nibbles causes the hang. I then tried to set write only, that is, a value of 0x2. That does boot. But then one can't readback the table. So, I'm stuck. I think I need to figure out how and where we tell the gx1 what address range maps to the SDRAM. --- Ian Smith [EMAIL PROTECTED] wrote: Ramesh, At 04:02 02/03/2005, ramesh bios wrote: 1. Shadow RAM I guess I would need to find a way to tell the northbridge to enable shadow RAM for some range around f. I looked through the CS5530A datasheet and see shadow registers but no mention of shadowing RAM. Nor in the GX1 datasheet either. I'm looking for some register in either the GX1 or the CS5530A that would enable this. I am looking for some register that would enable me to remap the C-F address range to somewhere in sdram. Is that the right thing to be looking for? I think you may need to look at your settings for the BC_XMAP_2 and BC_XMAP_3 registers on the GX1 - these control read and write access to the BIOS shadow ram regions. 2. Uncompressed payload I'm not sure I understand what this means. Right now, my payload is filo. In the build, I see: dd conv=sync bs=196608 if=/bios/filo-0.4.2/filo.elf of=payload.block cat payload.block romimage Oh, I guess you must mean this stuff: objcopy -O binary linuxbios_c linuxbios_payload.bin ./nrv2b e linuxbios_payload.bin linuxbios_payload.nrv2b So I guess there is some kind of compression going on there. Not sure if you're using Linuxbios V1 or V2 but in V1 there is an option in your build config file to turn off compression - you probably need something like: option CONFIG_COMPRESS=0 If it's V2 then no doubt there is an equivalent there too. Which method would be the right thing to do? I'll look at the shadow ram thing first then. Thanks. Nope this helps Ian --- Ronald G. Minnich rminnich@lanl.gov wrote: On Tue, 1 Mar 2005, ramesh bios wrote: Strike that. The issue is somewhere with copy_pirq_routing_table. IE: why does the copy to f fail. I had assumed that the 500 address was an alternate location that the table was copied to. So now, I'm looking at that f000 failure. the copy to f fails because shadow ram is not set up. You can fix this one of two ways. One is to figure out how to enable shadow ram. The second is to make the payload uncompressed. The copy will still fail but linux will find the PIRQ table anyway. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ Linuxbios mailing
Re: Geode GX1 and IRQ tables
for shadow ram, you need to enable writes to go to ram. Later on, when you are done with a region, you need to enable reads. So the way you do this: figure out which one is for 0xf. Enable writes (2). At the end of the process, you need to set (3) for the area. And, somebody will have to explain how this fits in with the new stuff, as I have not looked at shadow ram setup at all in V2! ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
* ramesh bios [EMAIL PROTECTED] [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
Re: Geode GX1 and IRQ tables
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 [EMAIL PROTECTED] wrote: * ramesh bios [EMAIL PROTECTED] [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 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
* ramesh bios [EMAIL PROTECTED] [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. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
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. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Mon, 28 Feb 2005, ramesh bios wrote: 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. no, it's messy. Some bioses set IRQ settings that don't agree with their own PIRQ tables. I've seen this in practice. So the fact that the normal BIOS has working IRQs means nothing. I'd like a URL for the Cox/Christer discussion :-) ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
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 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
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 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Strike that. The issue is somewhere with
copy_pirq_routing_table. IE: why does the copy to
f fail. I had assumed that the 500 address was an
alternate location that the table was copied to. So
now, I'm looking at that f000 failure.
--- ramesh bios [EMAIL PROTECTED] wrote:
The URL for the Cox/Weinigel thread about PIRQ
tables
on the geode gx1 is at:
http://lkml.org/lkml/2002/7/5/104
I'm doing a little bit more analysis of the problem
now. I've been looking at the following block of
code
from 2.6.10's pci/irq.c. First of all, LB states
this
during bootup:
---
Checking IRQ routing tables...
/bios/freebios/src/arch/i386/lib/pirq_routing.c:
30:check_pirq_routing_table() - irq_routing_table
located at: 0x8740
done.
Copying IRQ routing tables to 0xf...done.
Verifing priq routing tables copy at
0xf...failed
Wrote linuxbios table at: 0500 - 0664
checksum f9fe
---
I'm not sure why the copy to 0xf failed. That's
kinda odd but I'll live with it for now. Now, I put
some debug in the kernel code to see whether it
found
the pirq table and I saw:
---
no pirq_table so calling
pcibios_get_irq_routing_table
pirq_table=
---
coming from pcibios_irq_init. So based on the code
appended below, I believe that the kernel isn't
finding the pirq table. And I think this is because
the kernel's pirq_find_routing_table function only
looks from __va(0xf) to __va(0x10) whereas
LB
puts it at 500. The second attempt that the
kernel
makes to get the PIRQ table is with
pcibios_get_irq_routing_table and that fails too. I
need to look at that, but first I think I'll look
into
why the copy to f fails. In the meantime, any
advice?
---
static int __init pcibios_irq_init(void)
{
DBG(PCI: IRQ init\n);
if (pcibios_enable_irq || raw_pci_ops ==
NULL)
return 0;
dmi_check_system(pciirq_dmi_table);
pirq_table = pirq_find_routing_table();
#ifdef CONFIG_PCI_BIOS
if (!pirq_table (pci_probe
PCI_BIOS_IRQ_SCAN)) {
printk(KERN_WARNING no pirq_table
so
calling pcibios_get\n);
pirq_table =
pcibios_get_irq_routing_table();
printk(KERN_WARNING
pirq_table=%p\n,pirq_table);
}
#endif
if (pirq_table) {
printk(KERN_WARNING had
pirq_table\n);
pirq_peer_trick();
pirq_find_router(pirq_router);
if (pirq_table-exclusive_irqs) {
int i;
for (i=0; i16; i++)
if
(!(pirq_table-exclusive_irqs (1 i)))
pirq_penalty[i] += 100;
}
/* If we're using the I/O APIC,
avoid
using the PCI IRQ routing table */
if (io_apic_assign_pci_irqs) {
printk(KERN_WARNING using
io_apic to assign irqs\n);
pirq_table = NULL;
}
}
pcibios_enable_irq = pirq_enable_irq;
pcibios_fixup_irqs();
return 0;
}
---
--- Ronald G. Minnich rminnich@lanl.gov wrote:
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
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
__
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Tue, 1 Mar 2005, ramesh bios wrote: Strike that. The issue is somewhere with copy_pirq_routing_table. IE: why does the copy to f fail. I had assumed that the 500 address was an alternate location that the table was copied to. So now, I'm looking at that f000 failure. the copy to f fails because shadow ram is not set up. You can fix this one of two ways. One is to figure out how to enable shadow ram. The second is to make the payload uncompressed. The copy will still fail but linux will find the PIRQ table anyway. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
1. Shadow RAM I guess I would need to find a way to tell the northbridge to enable shadow RAM for some range around f. I looked through the CS5530A datasheet and see shadow registers but no mention of shadowing RAM. Nor in the GX1 datasheet either. I'm looking for some register in either the GX1 or the CS5530A that would enable this. I am looking for some register that would enable me to remap the C-F address range to somewhere in sdram. Is that the right thing to be looking for? 2. Uncompressed payload I'm not sure I understand what this means. Right now, my payload is filo. In the build, I see: dd conv=sync bs=196608 if=/bios/filo-0.4.2/filo.elf of=payload.block cat payload.block romimage Oh, I guess you must mean this stuff: objcopy -O binary linuxbios_c linuxbios_payload.bin ./nrv2b e linuxbios_payload.bin linuxbios_payload.nrv2b So I guess there is some kind of compression going on there. Which method would be the right thing to do? I'll look at the shadow ram thing first then. Thanks. --- Ronald G. Minnich rminnich@lanl.gov wrote: On Tue, 1 Mar 2005, ramesh bios wrote: Strike that. The issue is somewhere with copy_pirq_routing_table. IE: why does the copy to f fail. I had assumed that the 500 address was an alternate location that the table was copied to. So now, I'm looking at that f000 failure. the copy to f fails because shadow ram is not set up. You can fix this one of two ways. One is to figure out how to enable shadow ram. The second is to make the payload uncompressed. The copy will still fail but linux will find the PIRQ table anyway. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Geode GX1 and IRQ tables
Hi all,
I'd been away for a while. I have picked up another
geode gx1 to play with. Previously I used the
irq_tables from the pcm-5823 and that worked just fine
as far as I could tell. This time around, with this
board I hit trouble. I saw the:
PCI: No IRQ known for interrupt pin A of device
:00:0b.0.
in the log.
And so I ran getpir, replaced the irq_tables.c file,
rebuilt and reflashed. But I still get the same
problem. I tried adding pci=biosirq but the error
still occurs and appears to prevent getting ethernet
working.
Here's what getpir generated from my board. I'm gonna
go try to understand what all of this means. If anyone
has any advice or suggestions on what to do, please do
let me know.
Thanks!
Ramesh
---
const struct irq_routing_table intel_irq_routing_table
= {
PIRQ_SIGNATURE, /* u32 signature */
PIRQ_VERSION,/* u16 version */
32+16*3, /* there can be total 3
devices on the bus */
0x00,/* Where the interrupt router
lies (bus) */
(0x123)|0x0, /* Where the interrupt router
lies (dev) */
0x1020, /* IRQs devoted exclusively
to PCI usage */
0x1078, /* Vendor */
0x2, /* Device */
0, /* Crap (miniport) */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8
rfu[11] */
0xf6, /* u8 checksum , this hase to
set to some value that would give 0 after the sum of
all bytes for this structure (including checksum) */
{
/* bus, dev|fn, {link, bitmap},
{link, bitmap}, {link, bitmap}, {link, bitmap}, slot,
rfu */
{0x00,(0x0a3)|0x0, {{0x01, 0xdeb8},
{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x1,
0x0},
{0x00,(0x0b3)|0x0, {{0x02, 0xdeb8},
{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0x0deb8}}, 0x2,
0x0},
{0x00,(0x133)|0x0, {{0x01, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0,
0x0},
}
};
__
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Mon, 28 Feb 2005, ramesh bios wrote: PCI: No IRQ known for interrupt pin A of device :00:0b.0. what kernel? It matters. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
I used Linux 2.6.10. I'm reading through the list archive now for any related kernel issues. Thanks. --- Ronald G. Minnich rminnich@lanl.gov wrote: On Mon, 28 Feb 2005, ramesh bios wrote: PCI: No IRQ known for interrupt pin A of device :00:0b.0. what kernel? It matters. ron __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
On Mon, 28 Feb 2005, ramesh bios wrote: I used Linux 2.6.10. I'm reading through the list archive now for any related kernel issues. From 2.4.19 on, the IRQ parser for PIRQ tables for geodes is broken. That could be part of the problem. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
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. Therefore allowing the inference that 2.6.10 can read the table that was generated by the normal BIOS, right? What do you think? I'm now reading through the Alan Cox/Christer geode PIRQ discussion to see if I missed something. --- Ronald G. Minnich rminnich@lanl.gov wrote: On Mon, 28 Feb 2005, ramesh bios wrote: I used Linux 2.6.10. I'm reading through the list archive now for any related kernel issues. From 2.4.19 on, the IRQ parser for PIRQ tables for geodes is broken. That could be part of the problem. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
