[LinuxBIOS] Geode GX1 system IRQ handling
So I'm back to working on getting LB on my Geode-based MaxTerm 230 thin client again. I've built a test image from the Eaglelion 5bcm target that boots this machine. However, IRQ mapping is not working. I have no doubt that is because the MaxTerm differs from the 5bcm. :-) I'm not entirely sure how to proceed. I know I can create PIRQ tables, but in some posts, I've seen mention that this is outdated and ACPI should be used. Even if I were to build a PIRQ table, the usual method of booting with the system's default BIOS is out of the question. The MaxTerm only ran WinCE 3.0, and has a WinCE BIOS instead of a full PC BIOS. Unless someone knows of a WinCE system inspection tool that might reveal the IRQ assignments. Advice appreciated.... thanks, Jonathan
put the bios flash psrt in another machine that takes the same part, and run the getpir program. This should work. ron
On 8/15/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
put the bios flash psrt in another machine that takes the same part, and run the getpir program. This should work.
Unless its compressed. -- Richard A. Smith
Richard Smith wrote:
On 8/15/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
put the bios flash psrt in another machine that takes the same part, and run the getpir program. This should work.
Unless its compressed.
You mean, run getpir against the WinCE BIOS image? Please clarify what you're saying. I still can't use the WinCE BIOS to boot other OSes, so unless I'm misunderstanding you, I don't think that'll work. thanks, Jonathan
Unless its compressed.
You mean, run getpir against the WinCE BIOS image? Please clarify what you're saying. I still can't use the WinCE BIOS to boot other OSes, so unless I'm misunderstanding you, I don't think that'll work.
Exactly. The $PIR was just a table. Ron's guessing that if they used PIR then its probably just the table hanging out in the ROM in which getpir will find it. you can also hd (or other hexeditor) the image file and look for occurances of $PIR. There may be more than one so you have to go further to verify its a PIR table. -- Richard A. Smith
Richard Smith wrote:
Unless its compressed.
You mean, run getpir against the WinCE BIOS image? Please clarify what you're saying. I still can't use the WinCE BIOS to boot other OSes, so unless I'm misunderstanding you, I don't think that'll work.
Exactly. The $PIR was just a table. Ron's guessing that if they used PIR then its probably just the table hanging out in the ROM in which getpir will find it.
you can also hd (or other hexeditor) the image file and look for occurances of $PIR. There may be more than one so you have to go further to verify its a PIR table.
Oh, sweet! I hope that is indeed the case. I'll peek at the ROM image shortly. Can getpir read from a file, such as a binary image of the WinCE BIOS? thanks again, Jonathan
Richard Smith wrote:
Unless its compressed.
You mean, run getpir against the WinCE BIOS image? Please clarify what you're saying. I still can't use the WinCE BIOS to boot other OSes, so unless I'm misunderstanding you, I don't think that'll work.
Exactly. The $PIR was just a table. Ron's guessing that if they used PIR then its probably just the table hanging out in the ROM in which getpir will find it.
you can also hd (or other hexeditor) the image file and look for occurances of $PIR. There may be more than one so you have to go further to verify its a PIR table.
No $PIR in the image. What's my best "Plan B"? Options that I'm aware of include: 1) Find a way to enumerate IRQ assignments while booted into WinCE 3.0. 2) Guess. :-) Right now, the only devices I need that are lacking IRQ assignments are the USB controller and the NIC. Question: how is the kernel getting IRQ assignments for ide0 and the 2 serial ports? Without an IRQ table, I have to assume it's assuming standard IRQs for those devices. thanks, Jonathan
No $PIR in the image. What's my best "Plan B"? Options that I'm aware of include: 1) Find a way to enumerate IRQ assignments while booted into WinCE 3.0.
Can you run one of the pci enum tools that work under windows? That will give you _some_ info.
2) Guess. :-) Right now, the only devices I need that are lacking IRQ assignments are the USB controller and the NIC.
This might not be that bad of an option. What you really need to know is what PCI Int is hooked up to the device. There are only 4. This might work: For INT in INTA, INTB, INTC, INTD: Configure the NIC and set it to use IRQ 9. Then route INT to IRQ 9. Hook up a ethernet cable and see if you get Rx packets.
Question: how is the kernel getting IRQ assignments for ide0 and the 2 serial ports? Without an IRQ table, I have to assume it's assuming standard IRQs for those devices.
Yeah. Those have long time accepted defaults. -- Richard A. Smith
Jonathan Sturges wrote:
Richard Smith wrote:
Unless its compressed.
You mean, run getpir against the WinCE BIOS image? Please clarify what you're saying. I still can't use the WinCE BIOS to boot other OSes, so unless I'm misunderstanding you, I don't think that'll work.
Exactly. The $PIR was just a table. Ron's guessing that if they used PIR then its probably just the table hanging out in the ROM in which getpir will find it.
you can also hd (or other hexeditor) the image file and look for occurances of $PIR. There may be more than one so you have to go further to verify its a PIR table.
No $PIR in the image. What's my best "Plan B"? Options that I'm aware of include: 1) Find a way to enumerate IRQ assignments while booted into WinCE 3.0. 2) Guess. :-) Right now, the only devices I need that are lacking IRQ assignments are the USB controller and the NIC.
you should be able to look at irq assignments in wince. ron
Jonathan Sturges wrote:
Richard Smith wrote:
On 8/15/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
put the bios flash psrt in another machine that takes the same part, and run the getpir program. This should work.
Unless its compressed.
You mean, run getpir against the WinCE BIOS image? Please clarify what you're saying. I still can't use the WinCE BIOS to boot other OSes, so unless I'm misunderstanding you, I don't think that'll work.
thanks, Jonathan
what kind of bios chip is it? Or, failing that, do you have a place to get a bios image? ron
Jonathan, On Tuesday 15 August 2006 22:25, Jonathan Sturges wrote:
So I'm back to working on getting LB on my Geode-based MaxTerm 230 thin client again. I've built a test image from the Eaglelion 5bcm target that boots this machine. However, IRQ mapping is not working. I have no doubt that is because the MaxTerm differs from the 5bcm. :-)
What exactly does not work (error messages and so on)? I also started with the Eaglelion 5bcm for my AXUS-TC320 (with WinCE-Loader, no BIOS). On my first tries with LinuxBIOS Linux complained about a broken IRQ map, but I played around with the settings and now it works. Juergen
Hi Jonathan, please use plain text, no HTML.... On Wednesday 16 August 2006 13:58, Jonathan Sturges wrote:
PCI: No IRQ known for interrupt pin A of device 00:13.0. Please try using pci=biosirq. usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings! ...which basically means the entries for these devices in the IRQ map are either wrong, or missing. What's needed now is a way to determine those interrupts, and put them in the map. Did you have to go through a similar process on your board, and if so, can you detail what you did?
Yes, similar to my experience. I tried (no chance to read back any values due to WinCE-Bootloader instead of BIOS) with this irq map and it works. Source attached. Juergen
Juergen Beisert wrote:
Hi Jonathan,
please use plain text, no HTML....
On Wednesday 16 August 2006 13:58, Jonathan Sturges wrote:
PCI: No IRQ known for interrupt pin A of device 00:13.0. Please try using pci=biosirq. usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings! ...which basically means the entries for these devices in the IRQ map are either wrong, or missing. What's needed now is a way to determine those interrupts, and put them in the map. Did you have to go through a similar process on your board, and if so, can you detail what you did?
Yes, similar to my experience. I tried (no chance to read back any values due to WinCE-Bootloader instead of BIOS) with this irq map and it works. Source attached.
Juergen
Thanks for the irq_tables.c file; I'll compare it to what I've got and merge in the changes. Sorry if that last mail came out HTML; I don't intentionally compose it that way, and apparently Thunderbird's autodetect got confused. thanks, Jonathan
------------------------------------------------------------------------
Jonathan Sturges wrote:
I was aware of the issues with LB failing to copy the IRQ map, due to the GX1's cache not being enabled. However, I applied the two northbridge.c patches for enabling the cache, so now that much works. (By the way, can someone on the development team commit those cache patches? As of revision 2360, they're not included. I'll send links to the posts if needed.) But what I get now is that there is no IRQ defined for my on-board USB and Ethernet adapters. So 'insmod'-ing a driver for either results in this message:
sorry, please resend. ron
Ronald G Minnich wrote:
Jonathan Sturges wrote:
I was aware of the issues with LB failing to copy the IRQ map, due to the GX1's cache not being enabled. However, I applied the two northbridge.c patches for enabling the cache, so now that much works. (By the way, can someone on the development team commit those cache patches? As of revision 2360, they're not included. I'll send links to the posts if needed.) But what I get now is that there is no IRQ defined for my on-board USB and Ethernet adapters. So 'insmod'-ing a driver for either results in this message:
sorry, please resend.
ron
The 2 patches I applied are from these posts: http://www.linuxbios.org/pipermail/linuxbios/2006-May/014546.html http://www.linuxbios.org/pipermail/linuxbios/2006-May/014777.html Granted, both of these patches were offered up as "hacks," but they work, allowing the GX1 cache to be enabled and for the IRQ map to be successfully copied, so I endorse them. :-) thanks, Jonathan
Jonathan Sturges wrote:
Granted, both of these patches were offered up as "hacks," but they work, allowing the GX1 cache to be enabled and for the IRQ map to be successfully copied, so I endorse them. :-)
thanks, Jonathan
Committed as rev 2379, builds fine, not tested; let me know. thanks ron
Granted, both of these patches were offered up as "hacks," but they work, allowing the GX1 cache to be enabled and for the IRQ map to be successfully copied, so I endorse them. :-)
Committed as rev 2379, builds fine, not tested; let me know.
Woah.. Slow down there Tex. And give the authors of the patch(s) a bit of time to respond. :) My patch was for tyring to figure out if thats really what the problem was. The framework was failing to do it properly. I never applied that patch since it just covers up a problem rather than fixing it. I don't have the hardware so it was difficult for me to rework and fix it the Right Way. IIRC the problem was that the device chain was looking for a APIC cluster and not finding that it took a different route that did not call the cache init function. We need to find and fix the real problem rather than bandaid over the issue. Jonathan thanks for being the squeaky wheel and not letting this drop. Have you come up to speed yet on the device chain init code? I think this may just be a static dev tree issue. If nobody gets to it before me I'll try to look at it tonight. -- Richard A. Smith
Richard Smith wrote:
Granted, both of these patches were offered up as "hacks," but they work, allowing the GX1 cache to be enabled and for the IRQ map to be successfully copied, so I endorse them. :-)
Committed as rev 2379, builds fine, not tested; let me know.
Woah.. Slow down there Tex. And give the authors of the patch(s) a bit of time to respond. :)
sorry. It just seemd this had been lingering for a while. I dont' see an issue with the enable shadow patch, however. thanks ron
sorry. It just seemd this had been lingering for a while.
I dont' see an issue with the enable shadow patch, however.
Maybe there isn't. But I just didn't want to blindly go around the established way until we thought about it. So if your board dosen't have an APIC cluster whats the right way to describe that? -- Richard A. Smith
Richard Smith wrote:
Granted, both of these patches were offered up as "hacks," but they work, allowing the GX1 cache to be enabled and for the IRQ map to be successfully copied, so I endorse them. :-)
Committed as rev 2379, builds fine, not tested; let me know.
Woah.. Slow down there Tex. And give the authors of the patch(s) a bit of time to respond. :)
My patch was for tyring to figure out if thats really what the problem was. The framework was failing to do it properly.
I never applied that patch since it just covers up a problem rather than fixing it.
I don't have the hardware so it was difficult for me to rework and fix it the Right Way.
IIRC the problem was that the device chain was looking for a APIC cluster and not finding that it took a different route that did not call the cache init function.
We need to find and fix the real problem rather than bandaid over the issue.
Jonathan thanks for being the squeaky wheel and not letting this drop. Have you come up to speed yet on the device chain init code?
I think this may just be a static dev tree issue. If nobody gets to it before me I'll try to look at it tonight.
Heh... I'm glad to be the squeaky wheel, but thus far I've taken an implementer's stance with LB and haven't learned the code. I will try to take a look but it may be the weekend before I have any appreciable time for it. I can provide you hardware, if it will help. The thin clients I'm using can be had for US$10 on eBay. If you're in the states, I'll ship you one. thanks, Jonathan
Heh... I'm glad to be the squeaky wheel, but thus far I've taken an implementer's stance with LB and haven't learned the code. I will try to take a look but it may be the weekend before I have any appreciable time for it.
Well if you haven't been hacking on it the device code can be pretty difficult to follow but if you grok that then you pretty much grok all of LinuxBIOS structure.
I can provide you hardware, if it will help. The thin clients I'm using can be had for US$10 on eBay. If you're in the states, I'll ship you one.
I am. $10? How many extra do you have? Let me go look at whats on that puppy maybe I'll just buy one from you. I need something for some remote temp monitoring in my house. OLPC has a lot of my spare hacking cycles consumed so I may not be able to spend any more time on it than you. But physical hardware and having a project to use it on tends to up the priority level. -- Richard A. Smith
On 8/16/06, Jonathan Sturges <jsturges@speakeasy.net> wrote:
PCI: No IRQ known for interrupt pin A of device 00:13.0. Please try using pci=biosirq. usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
...which basically means the entries for these devices in the IRQ map are either wrong, or missing.
This means that PCI interrupt A was aserted but was not routed to any particular IRQ. So then its very likely then that IntA is wired to the USB bridge. Theres your first bit of routing info to try. This and lspci gives you most of the info you need. Take the existing $PIR table and change it such that IntA is routed to the IRQ of your choice ( an unused one is a good choice) and tell the dirver to use that irq. Now just because you have a irq table dosen't mean that the irq router gets magically setup. Depends on what the LinuxBIOS code does and what Linux does. Linux in the past has not done a lot of the IRQ routeing setup but its getting better all the time. You will need to look at the datasheet for the IRQ router to see what registers need to be dumped to see what PCI Int pins are routed to wthat IRQ. -- Richard A. Smith
participants (4)
-
Jonathan Sturges -
Juergen Beisert -
Richard Smith -
Ronald G Minnich