PC/104 ISA bridge VT82C686 - writing driver for self-made ISA board
 

Good day!

I'm trying to write a driver for a self-made ISA board, which is accessed via a PCI-ISA-Bridge. The details follow:

I'm working with a ISA board developed for experimental purposes at the university. The board has no intelligence at all, and its main purpose is to amplify the output coming from the ISA data bus and redirect it to other boards according to the ISA address bus. Now, I'm trying to use this board on a PC/104 computer running Debian etch, kernel 2.6.19.

To control my ISA board, I have to configure I/O ports 0x280-0x28f as my ISA address range. My problem comes when writing the driver for this board. This is the approach I took but it did not work:
- I wrote a simple pci-driver for the isa bridge; however, I cannot allocate the desired addresses (0x280-0x28f) to be driven by the isa bridge
- in fact, the driver could not allocate any address for the isa bridge (isa-bridge base address 0 - 5 remain at 0x0000)
- if I understand correctly, a pci device driver should assign automatically its address space. But how it should happen, if my ISA board has no intelligence (it is not a PnP board).


What should be the correct approach to solve this problem?

Extra info:
lspci -s 7.0
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] {rev 40}

cat /var/log/messages
localhost kernel: isapnp: Scanning for PnP cards...
localhost kernel: isapnp: no Plug & Play device found

PC/104 has the same electrical configuration as ISA, what changes is the form factor. So, in the software realm ISA=PC/104

Thanks for your attention,

jpmzometa

Doesn't the bridge take care of exposing the ISA-bus IO address space? If you tried to run your board under a real-mode OS such as MS-DOS, you would simply read/write IO ports in the range appropriate to the ISA card; any PCI involvement is transparent. What happens if you do something like:
(Change IO address 0x280 and write-word 0x123 to values appropriate to your application).
You will need to run this userspace application as root due to the hardware access.

... or have I completely misunderstood your question?


--- rod.

Thanks Rod!

You understood my question right.

Now, let me see if I got you.

Does it mean I should forget about writing a pci driver, and instead create a simple 'char' device driver, reserving my ioports using request_region(0x280, 16, "isa_dev")? Then the bridge should do the rest automagically , even if there is no driver attached to the ISA-Bridge? right now the ISA-bridge is using the parport_pc module (not what I want, I assumed, so I unloaded it); that's why I thought I should write my own pci drive (withouth succes until now).

I have no experience writing drivers. So far, I have only started reading a couple of books: "Linux Device Drivers, 3rd Ed." and "Linux-Treiber entwickeln, 2. Auflage". Following an example I found on internet, I manage to drive the parallel port.

I'll give it a try and let you know how it went.

Thanks a lot,

Chito

Yes, I think we agree on the question. I don't know many details of creating device drivers, but I'm pretty sure the ISA-bus management issues are already handled by the bridge. The parport_pc module is a standard parallel port management module, and is probably loaded in conjunction with another parallel port driver. The code fragment I posted is cribbed from some custom parallel port interface code I wrote recently. The target PC actually has no proper ISA bus, although the addressing used to access it falls into the real-mode ISA-bus address space. From userspace, one simply accesses port addresses for standard parallel port hardware. Your experience with the parallel port driver example would seem to confirm my belief. Please do followup to this thread if you encounter anything that counters my theory on this.
As I expect to convert my userspace pseudo-driver to a proper kernel module at some point soon, your example code sounds like an ideal starting point. Would you mind posting a link to it?
--- rod.

Today is not my lucky day.

Basically what I did, was:
- in the parallel port module I wrote before, I just change the address 0x378 by 0x280
- in module_init, I included outb(0xAA, 0x280)
- with a scope I was checking the ISA address and data buses

The scope showed some strange values, definitively not the values I was expecting. Actually, the signals were not all a constant +5V DC, some of them on the data bus were square wave with a +3.6V amplitude and 1.0kHz, and a very small duty cycle. And the address bus the story was the same, except that the frequency was 66kHz. Maybe I should check the ISA specification to try to understand what was going on.

Anyways, afterwards I tried writing the port from user-space, but I noticed no difference at the scope output. I tried different methods, but nothing seems to work. I missing a small detail for sure.

Now, I really do not know what to do!

Thanks anyways Rod,

Chito

If you are just monitoring ISA-bus pins, you should not expect to see much in the way of constant logic levels. Only after an address is decoded and latched in your bus-attached peripheral hardware is there likely to be any constant logic levels. What I would do is try writing a varying bit pattern to a constant IO port address that you expect you peripheral board to decode, and watch an appropriate output on the address decoding hardware (assuming it has pins physically exposed at that level). Do you have a PC/104<->ISA connector conversion card? If so, perhaps you can get hold of an old ISA parallel port expansion card and do some pokes and peeks at it to confirm that things are what you expect.
--- rod.

Thanks Rod.

I only have the PC/104 (are you familiar with it?). To the PC/104 I have attached the custom board. This board, as a matter of fact, has some latching circuitry.
First I looked at the output of the latches (some 74LS245 transceivers and 74LS573 latches), but all I got no matter what was +5V at the data bus, I did not check the address bus. After not seeing any progres, I decided to go to the raw output from the PC/104

Thanks Rod.

I only have the PC/104 (are you familiar with it?). To the PC/104 I have attached the custom board. This board, as a matter of fact, has some latching circuitry.
First I looked at the output of the latches (some 74LS245 transceivers and 74LS573 latches), but all I got no matter what was +5V at every pin of the data bus, I did not check the address bus. After not seeing any progress, I decided to go to the raw output of the PC/104 (just as explained in the previous message).

But now that you mention it, I think I'll stick to the latches' outputs rather than the PC/104's. Tomorrow I'll do some more test, and I'll drop you a line (if you do not mind :) ).

Thanks again, you are being really helpful!

Chito

Solved
 

Hey Rod!

You are my total hero!

I applied a fixed frequency read/write cycle to the port, and this time I could see the pulses coming and going. Again, not exactly what I expected, but I least I know I can write to the port just the way you said. I'm soooo happy :D

What was the problem? I had no idea how the ISA hardware works, so I was not getting what I expected.

THANKS A LOT!
VIELEN DANK!
GRAZIE MILE!
MUITO OBRIGADO!
MUCHAS GRACIAS!

Chito

Glad to hear it is as I expected. Would you mind posting a link to the sample code to which you referred earlier?
Thanks.

--- rod.

I'm using linux on a realtime application. For that purpose, I'm making use of RTAI (Realtime Application Interface for Linux www.rtai.org). The code I use to generate a 1kHz read/write cycle was based on a file found on the CVS of the project:
http://cvs.gna.org/cvsweb/?cvsroot=rtai

However, for this code to work, you have to have installed RTAI (which means, among several other things, download, patch and, compile a fresh vanilla kernel).

On monday I can post the small module I wrote, which is basically register i/o port 0x280 and create a char device.

Thanks again,

Chito

Doing some more test, I realized that I needed not to write a driver. There is no need even to request_region. The bridge handles it (just as you said)

For now, I am just using the inb, outb functions in the calling module (the one I used from RTAI's CVS, found on: showroom/v3.x/kern/i386/scb). It is running in kernel space, and is as simple as writing/reading periodically using kernel timers (no IRQ).

Maybe when I have more needs (IRQ, user space, etc.) it would be necesary to write a driver.

Thanks again Rod,

Chito