Re: PCI Memory/IO Address Mapping...

["Alexander Bezrukov" <alb_@pisem.net>]

Hello Abraham,

> I am a beginner to PCI and was reading Tom Shanley's
> PCI s/m architecture when i had the following doubts..
> they may be too novice... but could u help me out...

I must say, I didn't read the Tom Shanley's book.

> 1. what is the 'configuration software' that Shanley
> refers to? is it the s/m BIOS or PCI BIOS or the
> device driver?


The configuration work is done by BIOS at POST time
(i.e. eithr after the power-up or a wake event) and OS'es
PCI bus enumerator driver (for allowing hot-plug functionality).

> 2. if i just want to make a simple PCI interface (for
> the sake of connecting my old ISA card to a PCI bus --
> for useability of my old card), and i just want to do
> simple write/read operations + take care of 1
> interrupt from the card to the CPU, do i "have" to use
> configuration registers?

Yes, you have to.

> IS it necessary to use Cfg
> registers for bare tasks as these? can i live without
> it if i dont want PnP (which i understand is built in
> to PCI specs..)


In contrast to ISA, the PCI spec does not allow a device to
have "fixed" addresses. This means that the device must be
configured to use a address range. And the use of configuration
space registers is the only configuration mechanism allowed
by the spec. Technically, it is possible to not implement the
configuration space at all and make a device responding to
fixed addresses (as it being in the ISA case) but this introduces
a problem (there is no way for a BIOS and an OS to ensure
conflict-free resource allocation) and violates the spec.
Besides the resource allocation, config. registers serve for
much more functionality.

> 3. where do i specify the configuration registers for
> a PCI target? do i have to place a separate memory for
> the same or can i live without using any extra
> hardware if infact cfg registers are absolutely
> necessary? 


I am afraid, I do not understand your question well. I can
say only that you obviously do need to use some memory for
storage of address range information.

> 3. during a cfg access, how does the host/pci bus know
> that when a request for cfg access to a target on bus
> 0 comes from the CPU, an 'IDSEL' is to be given
> specifically to that target on bus 0. is there a
> register for this? 


Each device has its own IDSEL input. The implementations
may vary but the recommended and widely implemented way
is to connect one of AD[31::11] to IDSEL input of a device
(each device has its own AD[n]) and assert one of AD[31::11]
at a time. The access mechanisms from the point of CPU also
may vary (and they do) but in the case of IA-32 machines
so called "Config. Mechanism #1" is used. In short words,
the FSB<->PCI bridge provides 2 registers (located at fixed
addresses). One of them (CONFIG_ADDRESS) latches the
necessary address information (which is to be put on the AD
lines), accesses to the second (CONFIG_DATA) initiate
configuration cycles on the PCI bus (reads put the datum from
the PCI to CONFIG_DATA, write initiate write cycles with
datum from the CONFIG_DATA). More detailed description
you can see in the spec, section 3.2.2.3).

> 4. i dont understand how the mapping of PCI cfg
> register address space and i/o and mem address space
> is done? during boot, the i/o and mem address regions
> are "assigned" but how does the mapping takes place?
> is there something wrong in my understanding of the
> whole concept?


I am afraid, it is. In the most general case, the exact mapping
between address spaces as seen from a CPU and configuration
space of a device is not specified. In the case of IA-32 machines,
there exist 2 configuration mechanisms:1 and 2. The config. mech.
1 I have shortly described above, the mech. 2 is obsolete and is
not recommended. The latter uses the fixed IO address space range
to more or less directly map between CPU's IO space and config.
space of a device. There exist a couple of registers which "configure" this
configuration space mapping. After the device is configured
(i.e. Base Address Registers (BARs) are set up and the device is
enabled (by setting up of the Command register)), the device
become responding on memory and IO cycles (its address decode
logic uses the values written to BARs). There are other mechanisms
used in non-IA machines (e.g. spare addressing on Alphas).

> 5. Pls tell me if there is anything wrong in my
> understanding of the follwing: 
> 
> a newly installed pci card during boot time, gets it
> i/o and mem assigned by the bios if the card has a
> valid vendor id, else it doesnt.

It depends on how to understand the "valid vendor id".
If all vendor ids but 0xFFFF are valid, it is; except for the
hypothetical case when BIOS is unable to allocate the
resources for all the devices (e.g. there are 2 devices
which wants 4Gb of memory space each both in lower
4Gb of addresses).

> (in that case, we
> have to use a device driver to program the cfg
> registers... )

Device driver almost never needs to configure devices.
There are some exceptions though.

> in either case, a 'copy' of the cfg
> registers is kept by both the pci card as well as the
> OS...

It depends on an OS. There is no much need to keep the whole
copy of the config space somewhere else. Information in the
config. space may often change.

> in case a valid vendor id is detected, do we need a
> device driver since already Intrpts, etc have been
> assigned?  what is it that the device driver should do
> other than this? is it absolutely necessary?


Device driver normally is not responsible for the device
configuration (it does BIOS and/or an OS). Driver normally
must allow for a normal device operation. Also,
device can be enabled or disabled. Interrupts might often be
shared with other PCI and non-PCI devices and also can be
enabled or disabled. All details depend merely on an OS.

> Thanks in advance for ur time and patience,
> 
> (PS: i need all this for a small project of mine)
> 
> regards,
> abraham


I hope this may help you.

Regards,
Alexander

------------------
Get free mailbox 20 Mb at http://www.hotbox.ru