Messages in this thread | | | Date | Fri, 11 Jul 2008 13:10:45 -0600 | From | Jordan Crouse <> | Subject | Re: PCI-ISA Bridge not operating |
| |
On 11/07/08 14:58 -0400, David Brigada wrote: > David Brigada wrote: > > Jordan Crouse wrote: > >> On 11/07/08 10:58 -0400, David Brigada wrote: > >>> Hi, > >>> > >>> I'm working with the MSM800XEV board from Digital-Logic. This board > >>> uses a Geode LX800 for a CPU and has the CS5536 companion board also > >>> installed. The board works with an IT8888G IC that provides a PCI/ISA > >>> bridge to a PC/104 bus that is externally provided. > >>> > >>> If I boot with FreeDOS, I can twiddle I/O ports, and the proper ISA > >>> signaling comes over the PC/104 bus. In Linux, the /IOW or /IOR line > >>> goes low as expected, but the address doesn't come over the bus. The > >>> DOS that I'm running doesn't seem to have any specific drivers for the > >>> chip, I'm guessing that the hardware should "just work" --- the IT8888G > >>> is designed to grab I/O requests in the ISA range off the PCI bus after > >>> a short delay if nothing else grabs them first. > >>> > >>> I have a feeling that it has something to do with the CS5536 companion > >>> chip, as it seems as though there is a driver for a PCI/ISA bridge on > >>> that chip, though I can't get much detail from AMD's datasheet on that > >>> functionality. I do know that on the MSM800XEV, any such functionality > >>> is wired to the IT8888G, not the CS5536. > >>> > >>> There are two kernel config options related to the PCI IDs of the parts > >>> of the device that handle the ISA bus, CONFIG_SCx200_ACB and > >>> CONFIG_CS5535_GPIO. I've tried disabling both, but it doesn't seem to help. > >>> > >>> In lspci, the CS5536 PCI/ISA bridge is shown, but not the IT8888G. > >>> > >>> Any ideas? > >> ISA should indeed "just work". The only thing I'm wondering is if > >> the kernel is interfering (it shouldn't). I assume that since it works > >> in FreeDOS that there is no possibility that something on the PCI bus > >> is grabbing the cycles instead. > > > > That's what I'm thinking --- that the CS5536 PCI/ISA bridge is claiming > > the cycles. > > > >> How are you trying to access the device in Linux? Through a kernel module > >> or a user application running as root? > > > > I've tried both. I have a kernel module that I wrote for the hardware. > > When I couldn't get that working, I tried looping some code that keeps > > touching the same I/O port that I'm using. > > > >> Jordan > >> > > > > Dave > > Looking through the documentation for the CS5536, in the "CS56536 > Companion Device Data Book," section 5.2.8, it says the following: > > > If the SDOFF (Subtractive Decode Off) bit in the GLPCI_MSR_CTRL (MSR > > 51000010h[10]) is cleared (reset value), any PCI transaction, other > > than Configuration Read/Write, Interrupt Acknowledge, and Special > > Cycle transactions, not claimed by any device (i.3., not asserting > > DEVSEL#) within the default active decode cycles (three cycles > > immediately after FRAME# being asserted) will be accepted by GLPCI_SB > > at the fourth clock edge. > > This is the same behavior that the IT8888G chip uses --- it waits three > cycles for another device to claim it and then passes the transaction > along. I'm guessing that the CS5536 might be grabbing it (maybe it's > electrically closer, or the logic is more optimized) before the IT8888G > can handle it. > > Does this seem feasible as to what could be happening?
Sure, but then why does FreeDOS work? It shouldn't be any different when the bits hit the line.
Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
| |