On I/O and meory address space

[Ali Najafi <alinajafi@simei.aztech.com.sg>]

Hi all,

Some time back, there has been a discussion on mapping the registers of a
PCI device to memory or I/O in this mailing list. I seek your forgiveness if
this is going to be a repitition of what has been discussed before and
appreciate your patience.

I am designing a PCI I/F for a device which has less than 1K bytes of
registers. I have a few ways to implement resource allocation of my PCI device:

First way: Make all the registers memory mapped, any where in 32 bit address
space. The software people said that such a device has the following draw-backs:

1- Writing device driver and debugging it is very difficult for such a
device because it has to access memory locations above 1-meg. The tools that
they have enables them to easily test memory locations below 1-meg, but when
it comes to above that, they seem to have a hard time.

2- It is impossible to intercept accesses to the device because interception
of memory accesses is not possible. Therefore it is impossible to prevent
illegal accesses to the device (by illegal I mean accesses from anything
other than the device driver).

Second way: Make all the registers I/O mapped. For such an implementation,
considering the 256 byte limitation of I/O space, I will need 3 BARs to
address all the internal registers of the device. How confident can I be
that all the 3 BARs *will* get allocated? What makes me think that they all
will be allocated is that, it needs only less than 1K bytes.

Third way: Implement an indirect addressing scheme where there is an address
register and a data register and map the address and data registers to I/O.
This way, I will need only 1 BAR which occupies only a few bytes and I can
be sure that resource *will* be allocated to the device (if not some strange
condition prevents it).

What I like to do is to map everything to memory. This is what PCI spec has
suggested and also seems quite natural and practical and also helps using
the bus bandwidth efficiently. It is also OK to map evrything to I/O space
but before that I should be confident that all my 3 BARs *will* get
allocated or at least chances of a not-allocated BAR is very little. This
way, since the registers are mapped to I/O, the software people will also be
happy because it enables them to trap any access to the device. I personally
hate to implement the indirect addressing scheme because it wastes a lot of
PCI bandwidth, and makes the logic of the hardware as well as the software
communicating to the device more difficult. However, this way has the
advantage that it needs only a few bytes of system resources and therfore
chances that the BAR is not allocated is very little.

The above issues raise the following questions:

1- How difficult really is it to debug the device driver of a PCI device
mapped anywhere on a 32 bit memory address space?

2- How important really is it to trap all the accesses to a PCI (or any
other) device to prevent any access to that device except those gone through
the device driver? If I'm not mistaken, there are resources on a system that
a user can access and mess things up. Why then should we bother ourselves to
prevent accesses to a device?

3- Based on your experience and based on the available products, which one
of the above three methods are more common (map the registers anywhere in a
32 bit address space, map to I/O, implement an indirect addressing scheme,
and maybe 
a fourth one: map registers to memory below 1 Meg)? (Personnaly I prefer to
do the perfect thing rather than the common one. But this is not always the
appropriate criterion to make the design based on.)

4- How possible is it that a device asking for 3x256 bytes in I/O space will
not get allocated? If the chances are little, I'm done! In a detailed
posting on Aug, 22, 1996, David O'Shea has described a few issues in this
regard. He was suggesting to use both a memory mapped and an I/O mapped BAR
to point to the same registers. His suggestion would be good for me to
implement if I can be sure that all my 3 BARs *will* get allocated.

I would much appreciate any of your comments or suggestions. Even if you
have the smallest reply, please do not hesitate to send it.

A. Najafi
q´¡