The Peripheral Components Interconnect (PCI) bus originally for IBM-compatible PCS developed, there urgently the necessity for a fast, processor-independent bus system existed. Since that time this bus was established also for other computer worlds (e.g. the current Macintosh models on base of the Power PC, various workstations with DEC's alpha processor or in addition, the current UltraSparc of SUN).
Also the developers of the Hades and the Milan thought of this really universal interface. This development led there that one can actually use now the same extension cards on different computer platforms - if drivers for the system concerned are available in each case. Therefore it is long at the time to be occupied once more near with the PCI bus. First we provide an overview of the possibilities of the PCI bus, afterwards we will then become acquainted with the individual registers for the initialization and configuration of PCI cards. The termination forms then the conception from the PC well-known PCI BIOS for ATARI compatible computers by the example of Hades and Milan.
The PCI bus is specified for 32 bits long data with max. 33 mc/s and is optionally expandable on 64 bits and/or 66 mc/s. The clock may take however in principle any value between 0 and 33 mc/s. With 33 mc/s and 32 bits data capacity theoretical data transmission rates of up to 132 MB/s are possible, and in practice actual values close this theoretical maximum are attainable.
According to the electrical specification can be accommodated at a PCI bus up to four Slots apart from the host system. Over a PCI Bridge then still another further bus can be attached. If this is again a PCI bus, one can repeat the play also several times.
Each PCI device can contain several independent functions (multi function DEVICES), which can be responded also independently via the bus. Most at present available devices are however so-called ' single function DEVICES '.
With the multi-function cards one must differentiate two of reason on different versions:
For the fundamental functions of the PCI bus altogether 47 pins for Slave adapters as well as 49 pins are needed for master adapters. In addition the links of supply voltage come. Without an enumerating of all signals I would like to do here however, since this would blow up the documentation unnecessarily, and also not at all for the application of the PCI BIOS would be relevant. Therefore are alsoonly the most important, in the figures used signals, to be more near described:
AD[0..31 ] - ADDRESS/CData
Addresses and data are gemultiplext transmitted. The individual bytes of the 32-Bit of word are released over the lines / C/BE[0..3 ].
/ C/BE[0..3 ] - COMMAND/BYTE Enable
The bus command (different reading and schreibarten) contains and in the data phase the signal byte Enable for the data lines in the address phase.
IDSEL - Initialization DEVICE SELECT
Chip SELECT for initialization and configuration of the PCI card. For each PCI Slot its own line is available.
/ REQ - Request, is used only for bus mast ring
Bus request, for each Slot is available a line.
/ GNT - Grant, is used only for bus mast ring
Bus dispatching, for each Slot is available a line.
/ INTA - INTERRUPT Request A
Request of an INTERRUPT with single function DEVICES.
/ INTB, C, D - INTERRUPT Request B, C, D
These INTERRUPT lines may be used only by devices with several functional units (multi function DEVICES).
The remaining signals more or less serve the control during the different address and data phases and their synchronisation. One finds details in the PCI local bus Specification and the PCI system Design Guides, a good overview can one in addition, by means of the Elrad booklets 3/97 and 4/97 provide. Since we would not like to develop new PCI cards here, but from the PC area already available cards also the Hades, Milan and other compatible ATARI computers to make tasty would like, did we here without further hardware details, which are not relevant for driver adjustments. The correct processing of the signals should be taken over anyway by the PCI Bridges available in the computers.
Basically any PCI device can appear as bus masters. As bus masters this PCI device can transmit then independently data from its own storage area into the system memory of the host computer. This type of the background processing relieves the processor of the host computer very strongly. However therefore all PCI devices, which have to transport large quantities of data, should or fast transfers require, when bus masters can occur. E.g. SCSI CONTROLLERS or also modern network cards use the DMA (direct memory access) ability of the PCI bus, in order to transport data fast into that or from the primary storage.
The advantages on use of a bus-masterable PCI device quite particularly show up with ' genuine ' multitasking operating systems, since the saved computing time can be put to other processes there at the disposal. Under single Tasking it is subject to the fate of the programmer to pull from the bus master ability of a PCI device of advantages. An access, which waits only for the end of a transfer, is simpler to implement, given away by no-load operation of the processor however again the won time.
The bus-masterable PCI device requests the bus by setting its / REQ line. A master may use / REQ however only for its current access, not however, in order to protect itself the bus in the long term. The bus Arbiter of the host computer assigns the bus to this device by setting the appropriate / GNT signal. After the bus was assigned to the PCI device, this can execute its DMA access. If the PCI device does not release the bus within a certain time again, the host computer can get GNT line the bus by taking away / also again freely. The bus master must terminate then presently/immediately the access.
On the PCI bus altogether four " pegel" triggered INTERRUPT lines are available (INTA... intd). All devices with only one function may use only INTA, the other three lines are intended for the operation so-called ' multi function DEVICES '.
In the PCI specification is not defined and thus the respective board manufacturer one leaves the further processing of the INTERRUPTS. The INTERRUPT lines of the individual Slots can be connected therefore either as " ground through " bus (open drain) in each only erdenklichen combination, or however they are advanced individually by each Slot at the appropriate INTERRUPT CONTROLLER. According to an INTERRUPT request then the respective driver of this PCI device is responsible to recover the cause of the interrupt request.
In contrast to the quite ill Design of the ISA bus it is possible with the PCI bus therefore that several cards an INTERRUPT line divide (shared INTERRUPTS) - bottlenecks, how one could do them in former times from the DOSen, are avoided thereby. However then the assigned software drivers for the PCI cards must be able to process also INTERRUPTS, with which several devices an INTERRUPT line divide. More to this topic gives it then with the conception of the PCI BIOS.
The PCI specification describes also a mechanism, with which a PCI device can offer a exekutierbaren ROM code for a device-specific initialization to etc.. This ROM can contain thereby several different ROM images, in order to support the most diverse computers and processor architectures.
The OPEN BOATS standard for PCI designates FORTRAN programs in the ROM, so that the ROM code is slowly (because interprets), but but processor independent. The other possibility are " native " ROM images (for the respective platform which can be supported), about which the manufacturers make however no use (probably because then could be justified only with difficulty, why e.g. the same diagram card for a PowerMac usually for 100% are more expensive than for the Intel PC). natural can OPENBOOT images and native images in a ROM be accommodated together.
The magic word " Plug and Play " is very closely connected with the PCI bus. Because the leidige topic of the resources assignment for the hardware is only here over in suitable BIOS (PCI BIOS) elegantly solvable. In the ideal case the installation of of a new PCI card sees thus as follows from (in contrast to the PC is not necessary with a ATARI compatible repeated (or repeated) boats during the installation; -)
The PCI bus actually is configuring defined. But contain everyone PCI device a record of registers, which can be picked out during the boat process. Contained are here apart from information about the device (manufacturer, device, type class, possibilities, Waitstates, INTERRUPT...) also the necessary storage areas.
Thus it is possible for the BIOS to merge the card correctly in the system without resources conflicts or strike itself the user with DIP switches, Jumpern etc. must occur. At the Macintosh sector (NuBus) and at the Amiga sector (Zorro II/III bus) e.g. the problem of the autoconfiguring is solve since the existence of the respective bus systems (thus for over 10 years) by the way already!
The PCI standard designates meanwhile also optionally the " Hot Plug ability ", so that PCI cards can be changed even in operation. That may be made however in no case at the Hades or Milan, since this can lead to the destruction of the Main board or the card (for this feature special prerequisites are necessary).
In the Hades the at present common implementation with 32 bits and max. 33 mc/s is used. For the conversion of the PCI bus in the Hades thereby the ' PCI local bus Specification revision 2,0 ' was consulted. The binding to the CCU takes place via a reprogrammierbaren Xilinx building block, by which therefore also later extensions should be possible.
The INTERRUPT lines INTA - INTD of each Slots are summarized and thereafter the TT-MFP are supplied. By the use of a MFP as INTERRUPT CONTROLLER (only flank triggering possible), the binding corresponds to the PCI specification with the Hades actually not, there
in this all INTERRUPT lines as ' are level-triggered ' defined. This circumstance difficult more difficult naturally the correct implementation of INTERRUPT-HANDLEARN, which must consider this behavior accordingly. Better the use of a PCI BIOS, which relieves this " Schwerst" work of, is natural.
In the Hades there are 3 DMA (direct memory access) channels for the 4 PCI Slots altogether. PCI Slot 1 occupies DMA (direct memory access) channel 1 (highest priority), PCI Slot 2 is assigned the DMA (direct memory access) channel 2. Those / REQ and / GNT lines of the Slots 3 and 4 are summarized concerning DMA and occupy the DMA (direct memory access) channel 3 (lowest priority). The Busarbitrierung with the help of these signals is taken over by a further mini Xilinx.
Fig. 1: The components in the Hades, taken part in the function of the PCI bus
Also the Milan has a PCI bus with a data capacity of 32 bits with max. 33 mc/s. The binding to the CCU been made by a PCI Bridge of the company PLX. INTERRUPT over the Intel PCI ISA Bridge and the INTERRUPT CONTROLLERS available therein are processed and passed on as autovector INTERRUPTS to the CCU. The Busarbitrierung for the DMA accesses takes place in one of the Glue chips.
Fig. 2: Block diagram of the hardware structure used in the Milan
As previously mentioned, each PCI device has its own register record. An access to this configuration area always takes place via parallel setting of the IDSEL line of the ensprechenden Slots and the creation of the register address and the bus command Configuration READ or Configuration Write on the lines / C/BE[0..3 ]. The IDSEL line is separately available thereby for each Slot and by the Motherboard is out-coded. Only with this type of the control an access to the individual cards is directly possible after the RESET, since at this time still no address areas were assigned. That access to these registers becomes up the PC supplied by the PCI BIOS over the instruction Configuration READ / Configuration Write.
The PCI bus has the potential to simplify the configuration of supplementary tickets substantially. In addition however these PCI devices must make certain functions available (via registers) of the configuration software (PCI BIOS). In the following the registers of this pre-defined configuration area are thus presented. The accurate format of the registers (i.e. the number of implemented bits etc..) again wiederrum depends on the respective PCI device. However some general rules must be observed. So all registers must offer the possibility of reading the adjusted values backwards and these read data must represent a value, which the card for the current adjustments even uses.
The configuration registers will for the configuration, and used initialization for the handling of heavy errors, and should only by the initialization software (i.e. PCI BIOS) and possible error processing routines be used. The device drivers are to use only accesses to I/O and/or MEMORY of areas, in order to manipulate device-specific registers and thus the functionality of the PCI device.
Each PCI card contains a record of defined registers, which supply information about the card and which at all only enable the automatic assignment of resources. The register area is 256 bytes long and divides into one of the PCI-SIG (PCI - Special Interest Group) pre-defined and into a card-specific area. Only the necessary registers must be implemented the memory layout 64 byte to be enough, pre-defined area must however by each PCI card be kept and contain identification data of the card and the possibilities for the general check of the card in the respective PCI devices by the two areas. The following 192 bytes are given not by the PCI specification, but can be filled with manufacturer-specific information and analysed afterwards by the software driver.
The registers are analysed during the initialization of the PCI bus and must contain valid values therefore already directly after the RESET. Also later the registers must remain in the free access, have there needed for example the operational software (PCI BIOS) the information about the address areas and possible status information to be queried.
In order to find out, which cards are attached at the PCI bus now, one can select the Vendor ID in everyone the Slots available in the system. The host system therefore access to the configuration areas does not have to support available cards (without error message). Since for a Vendor ID the value FFFFhex is not permitted, it is therefore enough completely if the system hardware does not return the delivery this value with read accesses on the configuration area available cards evenly.
Each PCI device must ignore write accesses on reserved or not supported registers, i.e. the write access must be concluded at the PCI bus without error message. The data are rejected however by the card. Read accesses on reserved or not implemented registers must be likewise concluded without error message at the bus, and be returned a value of 0000hex.
Table 1: The pre-defined configuration registers
Configuration register | Address
Offset | |||
---|---|---|---|---|
DEVICE ID | Vendor ID | 00h | ||
Status | COMMAND | 04h | ||
Class code | Revision ID | 08h | ||
ARE | Header type | Latency timer | Cache LINE Size | 0Ch |
Cousin ADDRESS of register | 10h | |||
14h | ||||
18h | ||||
Çh | ||||
20h | ||||
24h | ||||
Reserved | 28h | |||
Reserved | 2Ch | |||
Expansion ROM cousin ADDRESS | 30h | |||
Reserved | 34h | |||
Reserved | 38h | |||
Max_lat | Min_Gnt | INTERRUPT pin | INTERRUPT LINE | 3Ch |
Table 1 shows the layout from the PCI-SIG defined 64Byte-Bereichs, which must support each card. It is naturally released to each PCI device to store further device-specific registers in the following area. All fields, consisting of more than one byte, are appropriate for the Little Endian (Intel) format as the base, i.e. the niederwertigere address contains also the niederwertigere byte.
The driver often commodity must deal with bit-coded fields carefully, since these mostly reserved bit locations for a any later use contain. The software must therefore with read accesses masks use around the used bits to extract, and may under no circumstances on certain values in reserved bits rely. With write accesses the software must guarantee the fact that the values of reserved bits are not changed, i.e. their value must beforehand selected and to the desired value of the other bits " gemerged " becomes.
Also this of the PCI-SIG pre-defined area is divided into two areas. First 16 bytes the long area applies to all types of PCI devices and is always alike. Different layouts can be assigned to the remaining 48 bytes as a function of the function of the PCI device. The field ' header type ' at address 0Ehex determines, which layout it concerns within this second area.
All PCI devices must implement the registers for Vendor ID, DEVICES ID, COMMAND and status. The implementation of the other registers is optional and depends again once more on the functionality of the PCI device. Implemented registers cannot being treated registers reserved by the PCI device like. If however a PCI device contains a function, whose behavior is determined through one of the defined registers, then the PCI device must make this register available in the place with the defined behavior, defined for it.
Five fields within the pre-defined area are intended for the identification of the device. All PCI devices must support these fields. The configuration software can determine thus easily, which devices at the PCI bus of the computer are available. All these registers are " READ only ".
This field identifies the manufacturer of the PCI device. Valid identifiers are assigned of the PCI-SIG to paying (!) members, in order to ensure a clarity. This manufacturer identifier is 16 bits long, whereby the value FFFFhex represents an invalid Vendor ID and from the Motherboard with an not occupied Slot one returns the delivery. On the basis this value thus the PCI BIOS can differentiate whether in the Slot concerned a card is available or not
This field identifies a special device. The identifier will assign to the software driver from the manufacturer of the card, and serves together with the Vendor ID to unique detecting of a PCI device. The function FindPCIDevice of a PCI BIOS makes use from this possibility. A special problem results however when using standard INTERFACE chip like the PCI9060. If one uses such an INTERFACE chip e.g. on a card even built, then this announces itself with its own Vendor and DEVICE ID and for a unique recognition and distinction of such cards is necessary therefore still another subsystem Vendor ID as well as subsystem a DEVICE ID. With this topic at a later point in time a further article will concern itself.
This register contains a device-specific revision number. The value will assign again from the manufacturer of the card, whereby also the revision number is permitted to 00hex. This field should be regarded therefore as manufacturer-specific extension to the DEVICE ID.
This byte determines both the layout of the bytes 10hex to
3Fhex of the configuration area, and the information whether the
device contains further functions. Bit 7 of this register is used in
order to indicate so-called multi function DEVICES. If the bit is 0,
then it concerns with this device a single function DEVICE, is it
however set, then this device has several functional units. Bits 6,,0
determine finally the format of the second section of the
configuration area. Pointed to table 1 the layout applies to standard
devices and is marked by header type 00hex. At present still header
is type
The Class code register is ' READ only ' and in addition is likewise only used, in order to determine the ' kind ' (the general function) of a PCI device, as well as in some few cases a register INTERFACE.
The register is partitioned in addition in 3 bytes. The highest byte (at address 0Bhex) represents the base class, which quite generally describes the function of this card. The middle byte (at address 0Ahex) is a Subklasse, which more exactly describes the function defined in the base class. With respect to the case of base class 02hex for network CONTROLLER is continued to differentiate here e.g. between Ethernet, token ring, FDDI and other types. The lowest byte (at address 09hex) is finally device-specific register INTERFACE, over which device-independent software with the device can communicate. Table 2 shows the defined values for the base class. The Class code enables at all only the co-operation of device-independent software with standard components as for instance to a diagram card, since there is evenly an abundance at different manufacturers (Vendor ID) and different compatible diagram cards (DEVICE ID), whom a driver would have to implement otherwise all.
Table 2: The definition of the base classes
Base class | Meaning |
---|---|
00h | PCI device was already manufactured before the definition of the Class codes |
01h | measure of STORAGE CONTROLLER |
02h | network CONTROLLER |
03h | display CONTROLLER |
04h | Multimedia DEVICE |
05h | MEMORY CONTROLLER |
06h | Bridge DEVICE |
07h - FEh | reserves |
FFh | device fits into none of the above classes |
This base class was defined, in order to ensure downward compatibility for those PCI devices, which were already built before the definition of the base classes. New devices may not use this value any longer, and older devices should transferring so far than possible to a more meaningful value. For this base class only two Subklassen, all other values exist are reserved.
Table 3: Base class 0
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
00h | 00h | 00h | all PCI devices except VGA compatible devices |
01h | 00h | VGA compatible devices |
This base class was defined for all possible applications of mass storages. So far no registers INTERFACES are defined for these devices
Table 4: Base class 1
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
01h | 00h | 00h | SCSI bus CONTROLLER |
01h | 00h | IDE CONTROLLER | |
02h | 00h | floppy disk CONTROLLER | |
03h | 00h | IPI bus CONTROLLER | |
80h | 00h | other one measured STORAGE CONTROLLER |
This base class was defined for the most diverse types at network cards. There are so far still no defined registers also here INTERFACES.
Table 5: Base class 2
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
02h | 00h | 00h | Ethernet CONTROLLER |
01h | 00h | token ring CONTROLLER | |
02h | 00h | FDDI CONTROLLER | |
80h | 00h | other network CONTROLLER |
This base class was defined for all types at diagram cards. In addition there are some Subklassen, to which its own register INTERFACE exists in each case.
Table 6: Base class 3
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
03h | 00h | 00h | VGA - compatible diagram card |
01h | 00h | XGA - compatible diagram card | |
80h | 00h | all other diagram cards |
This base class defines the possible types of Multimedia devices, for which however no specific registers INTERFACES are defined.
Table 7: Base class 4
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
04h | 00h | 00h | video |
01h | 00h | audio | |
80h | 00h | other Multimedia of devices |
This base class defines all possible types at MEMORY control-learns. No specific registers INTERFACES are defined.
Table 8: Base class 5
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
05h | 00h | 00h | RAM |
01h | 00h | FLASH | |
80h | 00h | other MEMORY CONTROLLER |
This base class is reserved for all possible types of ' bridge DEVICES '. Such PCI bridge is a PCI device, which mappt PCI resources (MEMORY or I/O) of page of this device on the other page of the device. There are several Subklassen, and no specific registers INTERFACES are defined.
Table 9: Base class 6
Base class | Subklasse | INTERFACE | meaning |
---|---|---|---|
06h | 00h | 00h | host bridge |
01h | 00h | ISA bridge | |
02h | 00h | EISA bridge | |
03h | 00h | MC bridge | |
04h | 00h | PCI to of PCI bridge | |
05h | 00h | PCMCIA bridge | |
80h | 00h | all other bridge DEVICES |
Over the COMMAND registers know the different possibilities of the PCI device over individual bits freigeschalten to become, if the device also supports this. The COMMAND register represents also a simple check of the PCI device whether it may PCI Cycles generate or to it answer. If one writes 0 into the COMMAND registers, then this device with exception of accesses to the configuration area is logically separate from the PCI bus. All PCI devices must put this functionality to the system at the disposal. The other bits in the COMMAND register can be implemented in dependency of the further functions and possibilities of the card concerned alternatively. A card, which permits e.g. no I/O to accesses, will not permit also a setting of the appropriate bit in the register. The PCI devices contain typically the value 00hex after that power UP, i.e. the functions are only released by the PCI BIOS (or also not).
Table 10: Bit in the COMMAND register
Bit | meaning |
---|---|
0 | IO space
0: Device does not react to I/O access 1: Device reacts to I/O access |
1 | MEMORY space
0: Device does not react to MEMORY access 1: Device reacts to MEMORY access |
2 | bus master
0: Device does not generate any accesses at the PCI bus 1: Device may appear as bus masters |
3 | Special Cycles
0: Device ignores Special Cycle operations 1: Device reacts to Special Cycle operations |
4 | MEMORY Write and Invalidate Enable (as bus
masters)
0: Device uses MEMORY Write of instruction as bus master only 1: Device may use MEMORY Write and Invalidate. |
5 | VGA pallet Snooping (bit must made available by
all VGA compatible devices weden)
0: Device treats pallet instruction like all different 1: Device does not answer to pallet instruction |
6 | parities error Response (devices, which check for
parities, this bit must support; Devices must always generate the
parity bit, even if the function is deactivated over this bit)
0: Device ignores parities - errors 1: Device signals and reacts to parities - to error |
7 | WAIT Cycle control
0: Device operates without address DATA stepping 1: Device operates with address DATA stepping |
8 | SERR # enable (parity one announced one set only
if also this bit)
0: Device may not signal a system error at pin / SERR 1: Device may signal system error at pin / SERR |
9 | almost bake-to-bake Enable (it determines whether
the PCI device may execute transactions as bus masters to different
targets; the initialization software sets this bit, if all targets
almost bake-to-bake capable signal)
0: Device may almost bake-to-bakes not to use 1: Device may as bus master almost bake-to-bakes uses |
10-15 | reserves |
The status register is used to it, in order information concerning PCI bus - relevant processes to the order to place. The PCI devices do not have to implement again wiederrum all bits, depend again on the functionality of the card. If a card acts e.g. as target, but never a target toilet signaled, also this bit will not be used by the card. Read accesses on these registers run normally, write accesses on this register can only reset but not set bits. A bit in this register is deleted, if one writes a 1 at the respective position. If one liked to delete e.g. bit 14, without impairing other registers, then one writes the value 4000hex into this register. In contrast to it the PCI device can these bits only set, but not reset.
Table 11: Bit in the status register
Bit | meaning |
---|---|
0 - 6 | reserves |
7 | almost bake-to-bake Capable (it displays, whether
the PCI device as target almost bake-to-bake transactions to several
targets verabeitet can)
0: none almost bake-to-bake transactions as target possible 1: Device understands as target also almost bake-to-bakes transactions |
8 | DATA parity Detected (one signals only if a parity
error occurs during a bus master access, and by the COMMAND registers
also freigeschalten became)
0: no parity error with master access or by COMMAND register closed 1: Parity error occurred with master access |
9 - 10 | DEVSEL timing (a PCI target it displays at
pin / DEVSEL that it registered access in an address, which is in an
address range assigned by the base address register; the value
determines, at which point in time after the address phase the pin
/ DEVSEL from High after Low changes.)
00: fast (after a PCI clock cycle) 01: means (after two PCI clock cycles) 10: slowly (after three PCI clock cycles) 11: reserved |
11 | Signaled target toilet (displays, if the PCI
device aborts the current transaction at the PCI bus)
0: no aborted transaction 1: Device aborted transaction with ' target toilet ' |
12 | Received target toilet (displays, if the PCI
device as bus master one acts and one aborts the current transaction
at the PCI bus by the target)
0: no aborted transaction 1: Target aborted transaction with ' target toilet ' |
13 | Received master toilet (displays, if the PCI
device as bus master one acts and one aborts the current transaction
with exception of Special Cycle at the PCI bus by ' master toilet ' -
all bus-master-capable devices must implement this bit)
0: no aborted transaction 1: Bus master - transaction was aborted by ' master toilet ' |
14 | Signaled system error (it displays, whether the
device signaled system at pin / SERR an error)
0: no system error 1: System error signals |
15 | Detected parity error (it displays, whether the
device detected a parity error - even if the parity handling by the
COMMAND registers abgeschalten became)
0: no parity error detected 1: Parity error detected |
The following registers are device-specific and must be made available only by those cards, which contain described functionality. For the standard operation these registers are not necessary.
This register determines the size of the Cache LINE in long words (32 bits). This register must be made available by all bus-masterable devices, which Write and Invalidate the command can generate. Devices to caching protocol are involved, use this register over to find out, when Burst accesses at the Cache are to be repeated boundaries. If the register is set to 0, the respective devices can ignore the PCI Cache lines / SDONE and / SBO. Devices, which make this register available, must set its value with RESETS to 0.
That standard access on the PCI bus is the Burst. A single access is thus nothing different one than after the first data item terminated Burst. Both the master and the Slave (target) can abort a Bursttransfer. The bus master aborts a transfer if the bus is extracted from it over / GNT, and its internal delay (latency timers) ran.
This register determines the value of the Latency of timer for bus master, and must therefore also by all bus-masterable devices be made available, which process more than two data phases in the burst mode. With two or fewer data phases in the burst mode this register can being executed also than ' READ only ', the value thus fixed should however smaller alike 16 (bus clocks) be. A quite spread implementation designates e.g. the lowest 3 bit as ' READ only ', while the upper 5 bits can be changed at will. Thus a dissolution of the Latency of timer of 8 bus results clocks. Is this register however as pure ' READ only' register executed, does not have to set the PCI device to its value with RESETS to 0.
This optional register serves for the control one on the PCI card implemented self-tests, if this is at all available. PCI devices no self check make available, return the delivery in this register the value 0. A device, whose self check was started, may impair the normal operation of the PCI bus in no keinster way.
Table 12: Bit in ARE register
Bit | meaning |
---|---|
7 | ARE capable
0: Device does not support a self check 1: Device makes an inserted self check available |
6 | start ARE
1: Self check start. After termination of the test this bit is set by the PCI device again to 0. Even if this does not apply at the flow of 2 seconds, then this card is to be classified as defective. |
5 - 4 | reserves |
3 - 0 | Completion code
0000: PCI device passed the self check. All values different of 0000 represent device-specific error codes. |
This 8-bit broad registers is used by the host system to generally make the information available about that the device assigned hardware INTERRUPT. The value in this register displays, which input of the INTERRUPT CONTROLLER is connected with the INTERRUPT pin of the PCI device. Both device drivers and the operating system can use this information in order to determine INTERRUPT priorities and vector information. The values in this register depend on the respectively used architecture. The value FFhex is used if no allocation to the INTERRUPT CONTROLLER could be determined, or if no connection to this exists. By the PCI device this register not one continues to consider.
The INTERRUPT pin register can be only read. Via this register the PCI device indicates to the host system, which INTERRUPT line of the PCI bus uses it. PCI devices, which do not generate INTERRUPTS, must set this register to 0.
Table 13: INTERRUPT pin register
Worth | meaning |
---|---|
0 | PCI device generate no INTERRUPTS |
1 | PCI device uses INTERRUPTS pin / INTA |
INTERRUPT | pin / INTB uses 2 PCI device |
3 | PCI device uses INTERRUPTS pin / INTC |
INTERRUPT | pin / INTD uses 4 PCI device |
5-255 | reserves |
These two ' READ only ' registers determine the limit values for setting the Latency of timer (only for the bus master operation necessarily). Both registers have here a dissolution of 0.25 microseconds. A value of 0 displays that this PCI device no special demands of the configuration of the Latency of timer makes.
MIN_GNT displays, how long the PCI device needs at least for only one Burst period (only one data phase) regarding a PCI clock rate of 33 mc/s. Thus the bus should be assigned to the PCI device (when bus masters) by the bus Arbiter for at least this time. MAX_LAT defined, for like for a long time the PCI device as bus master access to the PCI bus to obtain would like. From both values one can select then a suitable value for the Latency timer register. The bus master returns the bus only then if the bus Arbiter extracts the PCI bus from it over / GNT, and which ran own latency timers. A master may protect itself however not by constant activating / REQ line the bus in the long term, but only for the current access use. The algorithm to the Arbitrierung is however not determined in the PCI specification. The PCI devices should indicate therefore also such values, which enable an effective use both the PCI bus and their own internal resources.
The base addresses are one of the most important functions, in order to ensure a simple configuration and integration of PCI devices into the computer system. The six base address registers contain in the initialization phase (from the PCI BIOS) assigned the addresses to the access to the individual address areas of the PCI device. Bit 0 in these address registers can be only read and displays whether the address area is situated in the MEMORY area or in the I/O area.
Registers, which request a MEMORY area, must set 0 to the value 0 to bits. The registers are thereby either 32 bits or in addition, 64 bits long. For the Auskodierung of the base address the PCI device uses however only bits 4 to bits 31 or Bit63, i.e. MEMORY areas always begin at 16 byte - boundaries. The other bits are ' READ only '. In bit 3 of the register it is indicated whether the address range is ' prefetchable ', and in bit 2 and bit 1 the desired type of the MEMORY is mappings in the initialization phase.
Table 14: Address register for MEMORY areas
Bit | meaning |
---|---|
31(63)..4 | MEMORY base address (32 or 64 bits long) |
3 | Prefetchable |
2 - 1 | type (the register 32/64 bit would pour, as
well as desired address area)
00: 32 bits long, arbitrary in 32 bits the address area 01: 32 bits long, address area below 1 MB 10: 64 bits long, arbitrary in 64 bits the address area 11: reserved |
0 | MEMORY space indicator = 0 |
Registers, which request an I/O area, are always 32 bits long and must in bit 0 the value 1 return the delivery. Bit 1 is reserved (READ only) and must be always deleted, all other bits (bit 2 to bits 31) finally describes the address in the I/O area, i.e. these areas always begin at 4 byte - boundaries.
Table 15: Address register for IO areas
Bit | meaning |
---|---|
31..2 | I/O base address |
1 | reserves (always 0) |
0 | IO space indicator = 1 |
Altogether workstation for six address registers is in the configuration area. The first address register always begins at offset 10hex. The position of the second address register depends then however on the size of (32/64 bit) of the first register, and therefore begins at offset 14hex or 18hex. Diagram cards request typically an I/O area for the control registers and a MEMORY area for the diagram memory. If a PCI device wants to put its control registers into the MEMORY and into the I/O area, it must " spendieren " for it also two address registers. Basically it all PCI devices should enable, to control registers into the MEMORY area to briefcases. That developed from the inadequacy of the PC's, which possess a much to small I/O area.
In order to determine now, how much memory requests the respective device by means of the address registers, the host system describes each address register with the value FFFF'FFFFhex and reads thereafter the register backwards again. The PCI device supplies at those bit locations 0 back, it to the Auskodierung of the desired storage area uses. If the device requests e.g. a 1MB large MEMORY area in the 32-bit address area and 256 byte a large I/O area, then one finds FFF0'0000hex for the MEMORY area after describing with FFFF'FFFFhex in an address register and in the other FFFF'FF01hex for the I/O area. The host system can assign in accordance with it the base addresses for the respective PCI devices. Starting from this point in time the PCI devices decode the accesses then out. The assignment of the address areas with boats of the computer system is function of a PCI BIOS.
The idea to the PCI BIOS for the ATARI compatible computers developed from the necessity for the allocation of storage areas to the I/O and MEMORY areas of the PCI devices.
On PC's and compatible ones PCI functionality is made available over an Bios extension (the PCI BIOS) standardized. The Bios has two substantial functions. On the one hand the supply of an interface for the software for the access to the PCI devices, on the other hand the initialization and the distribution of the resources of the individual PCI devices. The initialization runs without direct access of the user directly after the RESET.
After the RESET the host system tests first the presence of the installed PCI devices. These effected via the access to a defined register (Vendor ID). at this time are possible for access to the still unknown cards only with the instruction Configuration READ and Configuration Write. After it out-gets the system has whether and where cards are in the computer, with all PCI devices the necessary address areas is determined. This occurs as previously mentioned with the writing of the value FFFF'FFFFhex into the respective address register.
Each PCI device can request max. 6 storage areas. The address range in the address register, needed in each case, is bit by bit out-masked. For coding for example bits 0 to bits 9 are used (out-code with FFFF'FC00hex), the area 2^10 is, thus 1024 bytes large. There is the selection between I/O gemappten and MEMORY gemappten areas (see articles in output 5/98). For a PCI device the two areas differ on only by the different commands / C/BE[0..3 ].
As response the host system (BIOS) assigns in each case address ranges to the individual devices - if in the address area enough workstation is available. Here e.g. the Hades in the comparison to the PC has to offer some more, since in the PC the I/O area is very limited. The Hades offers in our case 256 MB to I/O area and 512 MB MEMORY area. That should really be sufficient for the start; -) After the log-on the PCI devices then are responsible for the Auskodierung of their address areas. The assigned address areas can be selected for the later accesses to I/O and MEMORY area from the configuration registers of the devices also again.
In a register of the defined configuration area (INTERRUPT pin) by each PCI device the INTERRUPT line used in each case is indicated. The BIOS assigns thereupon and further functionality puts to one of the available INTERRUPTS over BIOS routines at the disposal.
The driver of an installed PCI hardware therefore passes through the following steps for the initialization and following use of a PCI board:
The further access to the attached PCI devices after the initialization and configuration access to the accordingly assigned address ranges is thus made by MEMORY and/or I/O. For this access no special Bios would be more necessary, but the PCI BIOS offers however evenly also here a simple accessability on these storage area/registers of a PCI device, without having to worry about any off sets and byte Orderings (Intel/Motorola).
Milan owners can skip the following paragraphs of calm conscience (it to read harms in addition, not), because the Milan the PCI BIOS already in the TOS integrated. Thus, switching on on and equal lot putting reads here the foreign exchange.
When Hades owners one copies PCI_BIOS.PRG from the file simply into the AUTO file, if possible at the beginning, but in any case before device driver PCI cards accesses and for it the BIOS interface already needs. The PCI BIOS creates in addition one _ PCI Cookie, over which then localizes the BIOS routines and to be used can. Details in addition are also in the ATARI PCI BIOS Specification (the current output carries the version number V1.12). at the Hades exist however additionally also still the possibility, a Low level BIOS (PCI_CONF.PRG of Torsten long) to install, which supplies the necessary information about Subcookies after the initialization of the PCI devices. Too PCI_CONF.PRG one can inquire details at the author Torsten long.
If one starts thus PCI_CONF.PRG forwards PCI_BIOS.PRG, then _ a PCI Cookie is already present. The I-BIOS used then already of PCI_CONF information supplied over the Subcookies and contributes then (only) still the interface for the BIOS routines. Also the INTERRUPT handling is then passed on from the PCI BIOS PCI_CONF. Since it will however not give for the Milan a PCI_CONF.PRG, the driver programmers should use excluding the standardized BIOS interface, which does not exclude however again wiederrum the use of PCI_CONF. Device drivers, which " nourish themselves, do not become " however only of the Subcookies of the PCI_CONF on other ATARI compatible PCI computers as the Milan not to function.
If one uses PCI_BIOS.PRG alone, then it (with exception of the supply of the Subcookies) takes over the functions of PCI_CONF.PRG and creates _ the PCI Cookie with the information itself necessary for the BIOS interface. The information, which PCI_CONF would normally supply over Subcookies, is however not lost, because for this the PCI BIOS makes the standardized routine available get_resource .
To receive described in the following thus the software INTERFACE, which can be used by the PCI device drivers and other operational software, in order access to the PCI cards in ATARI compatible systems. Details can be reread also in the current in each case output of the ATARI PCI BIOS Specification. After all Vorraussicht one will find these in the near future under http://www.milan computer.de.
The PCI Bios installs " _ PCI" Cookie for one, via which the BIOS routines can be localized and addressed. For programmer there is for this already a PCI LIBRARY, who completes these functions, and thus very simple access permits. The current in each case versions of the PCI BIOS for the Hades and the appropriate PCI LIBRARY are to be found under http://www.wvnet.at/privat/97021702 /. Further there is a c-sample program here also for the use of this LIBRARY. As soon as the generally valid ATARI PCI BIOS Specification is available in the Internet, will it also one link here on it to give. With the Milan the BIOS routines will be fixed integrated in one of the next versions of the Milan TOS, an appropriate program in the AUTO file are not necessary in contrast to the Hades thus then any longer. Whether and when this possibly also with the Hades the case its becomes, can be said at this time not yet.
Each PCI device of the PCI BIOS deviceconcern assigned, with which these devices can be addressed then. Conclusions of do not deviceconcern on the PCI Slot concerned are possible, and also not desired. In the following calls in assembler and C, the information is represented to the used parameters completes themselves in each case mutually. All PCI BIOS routines must be called in the supervisor mode.
The following error codes can be returned the delivery in the event of an error by the BIOS routines.
Table 16: Error code of the BIOS routines
Error code | name |
---|---|
$00000000 | PCI_SUCCESSFUL |
$$FFFFFFFE | PCI_FUNC_NOT_SUPPORTED |
$$FFFFFFFD | PCI_BAD_VENDOR_ID |
$$FFFFFFFC | PCI_DEVICE_NOT_FOUND |
$$FFFFFFFB | MORE PCI_BAD_REGISTER_NUMBER |
$$FFFFFFFA | PCI_SET_FAILED |
$$FFFFFFF9 | PCI_BUFFER_TOO_SMALL |
$$FFFFFFF8 | PCI_GENERAL_ERROR |
$$FFFFFFF7 | PCI_BAD_HANDLE |
The following two error codes are used not by the BIOS routines themselves, are however reserved for a PCI LIBRARY.
Table 17: Error code of the PCI LIBRARY
Error code | name |
---|---|
$$FFFFF001 | PCI_BIOS_NOT_INSTALLED |
$$FFFFF000 | PCI_BIOS_WRONG_VERSION |
This function serves for to look a certain PCI device up (a PCI card can accommodate again wiederrum several functional units = devices) over DEVICES and Vendor ID. Thus a software driver finds thus its appropriate hardware, if it was installed also in the computer. If a hardware should be several times in the system available, or two cards with the same IDs to announce itself, so the individual cards are queried over their index. One begins thereby with index 0 and increases him then until the routine returns the delivery the error code PCI_DEVICE_NOT_FOUND.
Call in assembler:
Call in C:
Special case:
with Vendor ID FFFFhex one can look all PCI devices up available in the system, which DEVICE ID ignored in this case.
This function serves to look a certain PCI device up over their Classcode. With this function it is e.g. possible to achieve the diagram card without knowing the manufacturer or the DEVICE ID. This function leads naturally only to success even if the PCI device uses one the determined Class code. There are several PCI devices with the same Classcode, then the device driver can the further cards over their index test. One begins thereby with index 0 on and increases him then until the routine returns the delivery the error code PCI_DEVICE_NOT_FOUND.
Call in assembler:
Call in C:
These three functions permit read accesses on the configuration registers of a PCI device, whose deviceconcerns or was determined find_pci_device before find_pci_classcode by means of.
Call in assembler:
Call in C:
These three functions permit a reading from registers in the configuration area without complex error and
Plausibility CHECKS and are also somewhat faster therefore than their 3 sisters (therefore it particularly suitably for INTERRUPT routines and if one knows quite exactly, what one does; -). Register contents are stored in the Returnwert. Thus these functions in c-programs can be still more easily applied.
Call in assembler:
Call in C:
Examples:
1)device_vendor = fast_read_config_longword (handle, 0)
the Vendor ID supplies and in the bits 16-31 the DEVICE ID in the bits 0-15
2)vendor = fast_read_config_word (handle, 0)
the Vendor ID returns the delivery
3)device = fast_read_config_word (handle, 2)
the DEVICE ID returns the delivery
4)timer = fast_read_config_byte (handle, 13)
supplies the schliesslichen value of the Latency of timer
These three routines serve for the writing of configuration registers of a PCI device.
Call in assembler:
Call in C:
For each PCI INTERRUPT it knows a whole chain of INTERRUPT-HANDLEARNS to give, since also several PCI devices the same INTERRUPTS can divide (see also articles in the output 4/98). Over deviceconcern can now a device driver his own INTERRUPT Handler by hook_interrupt into the suitable chain enter let, without having to know the INTERRUPT responsible for it.
Footstep thereafter an INTERRUPT up, by the BIOS the Handler entered into the chain is called in sequence. Each INTERRUPT Handler becomes thereby with that one Parameter called, which was specified with the call hook_interrupt of. This parameter is completely freely selectable by the device driver, selection suitable with one would know with only one driver also several (identically constructed) devices parallel serve. The INTERRUPT Handler must check immediately after its call whether the INTERRUPT was released by the card cared for by them, and accordingly to react. That is, the INTERRUPT cause is to be recovered, and the appropriate bit of the BIOS internal parameter is to be set. If the appropriate device did not release the INTERRUPT, the INTERRUPT Handler may change the BIOS internal parameter under no circumstances!
The Handler is to be regarded as normal procedure, i.e. also in assembler the INTERRUPT Handler with RTS is locked.
Call in assembler:
Call in C:
Hangs the INTERRUPT Handler of the driver into the chain of the appropriate INTERRUPT channel. Beforehand still if no Handler was in the chain, also the PCI INTERRUPT concerned in the host system is activated. After occurance of the respective INTERRUPT the indicated INTERRUPT Handler is thus called. However it is to be made certain in particular that the INTERRUPTS on the PCI device may be activated only after the call of this function, since it can come otherwise too spurious INTERRUPTS.
If a INTERRUPT Handler is already announced for the selected PCI device, then one receives an appropriate PCI BIOS error code. It is to be advised against urgently to remove unhook_interrupt by other Handler. For this purpose there is the function get_card_used, over which a call baking routine of the other driver can be determined. The call of this call baking routine gives then the possibility to the other driver of deinstallieren itself cleanly and arrears-free.
Call in assembler:
Call in C:
With this routine one can remove one hook_interrupt by means of announced INTERRUPT Handler again. The driver must note however that the INTERRUPTS on the PCI device must be deactivated before the call of this BIOS function, since it can come otherwise too spurious INTERRUPTS.
Call in assembler:
Call in C:
All information supplies to the resources of a PCI card (or a PCI device in the case of multi-function cards). The returned the delivery information may not be under any circumstances changed by the device drivers. The device driver can on the basis the offered information (byte ordering etc..) the card then directly address. A further possibility is the use of the BIOS routines read_mem_..., write_mem_..., read_io_... and write_io_..., whereby one must worry then about no secondary conditions themselves.
The routine supplies a pointer on the first resource descriptor of the desired PCI device. The device driver can achieve then the further descriptors by means of an offset (length of a descriptor). The last descriptor of the device is particularly marked again wiederrum. The sequence of the Despriptoren corresponds those of the base address registers in the PCI Konfigurationsbereich. A PCI device can request/use also several resources of the same type.
Call in assembler:
Call in C:
Table 18: Structure resource of a descriptor
Name | Size of | description |
---|---|---|
NEXT | WORD | length of this structure in bytes, serves for the determination of the next Deskiptors |
flag | WORD | type of resource and different other flags |
start | LONG | start address of the resource in the PCI address range, is not directly addressable the resource, then the address is 0 |
length | LONG | length of the resource |
offset | LONG | offset of the physical PCU ADDRESS to the PCI address |
dmaoffset | LONG | offset for DMA (direct memory access) transfers to of/to primary storages |
private | x BYTE | BIOS internal data, may not be changed |
In order to determine the descriptor of the next resource of the PCI device, one must add the field NEXT for the start address of the current descriptor. The field start indicates the beginning of the appropriate resource in the PCI address range. If this resource should not be directly addressable, then the address 0. is located over length can one the length of this resource finally determine in this field. The PCI address range is not to be equated generally with address seen by the CCU from. The address offset, which is to be added to the PCI address, in order to determine the physical address for the CCU, is in the field offset store-storing that entry dmaoffset finally indicates the offset, which must be added to the PCI address, if it concerns DMA (direct memory access) transfers.
Table 19: The flags in the resource descriptor
Name | Flag | description |
---|---|---|
RSC_IO | an I/O area, with deleted bits concerns it indicates $4000 a MEMORY area | |
RSC_LAST | $8000 | last resource for this PCI device |
FLG_8BIT | $0100 | 8 bits accesses are supported |
FLG_16BIT | $0200 | 16 bits accesses are supported |
FLG_32BIT | $0400 | 32 bits accesses are supported |
FLG_ENDMASK | $000f | indicates the byte Ordering:
0: Motorola (big endian) 1: Intel (little endian), ADDRESS swapped 2: Intel (little endian), lane swapped 3..14: reserved 15: unknown, access only over BIOS possible |
If the resource in the Motorola format (0) is present, one needs to do nothing further. All accesses run as used. If it concerns however the Intel format, is to be differentiated as a function of the implementation in terms of hardware of the PCI bus in the host system between two different possibilities:
Who does not want to argue with all that more near, that should rather nevertheless equal the BIOS routines mentioned above use, which execute the if necessary necessary modifications independently. If the byte Ordering is unknown (15), one must endeavor the in any case BIOS for all accesses.
The following routines were not published yet in the appropriate article of the ST computers. As soon as the article in the output appeared 10/98, I will again insert the descriptions of the following routines.
Summary
Markus spruce farmer
Hans riding ago lane 1
A-3950 Gmuend
AUSTRIA
mailto:fichti@wvnet.at
http://www.wvnet.at/privat/97021702/index.htm
[ 1 ] PCI local bus Specification revision 2.0
[ 2 ] Elrad 3/97 and 4/97 (bus Basics - technical bases of the PCI bus)
[ 3 ] PCI Special Interest Group
P.O. Box 14070
OR 97214, port country, the USA
http://www.pcisig.com