Bus Specifics
This section covers addressing and device configuration issues specific to the buses that the SunOS system supports.
PCI Local Bus
The PCI local bus is a high-performance bus designed for high-speed data transfer. The PCI bus usually resides on the system board and operates at speeds close to those of the host processor. The PCI bus is normally used as an interconnect mechanism between highly integrated peripheral components, peripheral add-on boards, and processor or memory systems. The processor, main memory, and the PCI bus itself are connected through a PCI host bridge, as shown in Figure 2-1.
A tree structure of interconnected I/O buses is supported through a series of PCI bus bridges. Subordinate PCI bus bridges can be extended underneath the PCI host bridge to allow a single bus system to be expanded into a complex system with multiple secondary buses. PCI devices can be connected to one of these secondary buses. In addition, other bus bridges, such as SBus or ISA-bus, can be connected.
Every PCI device has a unique vendor ID and device ID. Multiple devices of the same kind are further identified by their unique device numbers on the bus where they reside.
Typical PCI devices include SCSI adapters, graphics and display adapters, host bus adapters, network controllers, and so on.
Figure 2-1 Machine Block Diagram
The PCI host bridge provides an interconnect between the processor and peripheral components. Through the PCI host bridge, the processor can directly access main memory independent of other PCI bus masters. For example, while the CPU is fetching data from the cache controller in the host bridge, other PCI devices can also access the system memory through the host bridge. The advantage of this architecture lies in its separation of the I/O bus from the processor's host bus.
The PCI host bridge also provides data access mappings between the CPU and peripheral I/O devices. It maps every peripheral device to the host address domain so that the processor can access the device through memory mapped I/O or special I/O instructions. On the local bus side, the PCI host bridge maps the system memory to the PCI address domain so that the PCI device can access the host memory as a bus master. Figure 2-2 shows the two address domains.
Figure 2-2 Host and Bus Address Domains
PCI Address Domain
The PCI address domain consists of three distinct address spaces: configuration, memory, and I/O space.
PCI Configuration Address Space
Configuration space is defined geographically; in other words, the location of a peripheral device is determined by its physical location within an interconnected tree of PCI bus bridges. A device is usually located by its bus number and device (slot) number. Each peripheral device contains a set of well-defined configuration registers in its PCI configuration space. The registers are used not only to identify devices but also to supply device configuration information to the configuration framework. For example, base address registers in the device configuration space must be mapped before a device can respond to data access. Figure 2-3 illustrates the configuration space registers.
Figure 2-3 PCI Configuration Address Space
The method for generating configuration cycles is host dependent. In x86 machines, special I/O ports are used. On other platforms, the PCI configuration space may be memory-mapped to certain address locations corresponding to the PCI host bridge in the host address domain. When a device configuration register is accessed by the processor, the request will be routed to the PCI host bridge. The bridge then translates the access into proper configuration cycles on the bus.
PCI Configuration Base Address Registers
The PCI configuration space consists of up to six 32-bit base address registers for each device. These registers provide both size and data type information. System firmware assigns base addresses in the PCI address domain to these registers.
The firmware identifies the size of each addressable region by writing all 1's to the base address register and then reading back the value. The device will return 0's in all don't-care address bits, effectively specifying the size of the address space.
Each addressable region can be either memory or I/O space. The value contained in bit 0 of the base address register identifies the type. A value of 0 in bit 0 indicates a memory space and value of 1 indicates an I/O space. Figure 2-4 shows two base address registers: one for memory; the other for I/O types.
Figure 2-4 Base Address Registers for Memory and I/O
PCI Memory Address Space
PCI supports both 32-bit and 64-bit addresses for memory space. System firmware assigns regions of memory space in the PCI address domain to PCI peripherals. The base address of a region is stored in the base address register of the device's PCI configuration space. The size of each region must be a power of two, and the assigned base address must be aligned on a boundary equal to the size of the region. Device addresses in memory space are memory-mapped into the host address domain so that data access to any device can be performed by the processor's native load or store instructions.
PCI I/O Address Space
PCI supports 32-bit I/O space. I/O space may be accessed differently on different platforms. Processors with special I/O instructions, like the Intel processor family, access the I/O space with in and out instructions. Machines with no special I/O instructions are usually memory-mapped to the address locations corresponding to the PCI host bridge in the host address domain. When the processor accesses the memory-mapped addresses, an I/O request will be sent to the PCI host bridge. It then translates the addresses into I/O cycles and puts them on the PCI bus. Memory-mapped I/O is performed by the native load/store instructions of the processor. For example, reading from or writing to a memory mapped data register can be done by a load or store instruction to that register's I/O address.
PCI Hardware Configuration Files
Hardware configuration files should be unnecessary for PCI local bus devices. However, on some occasions drivers for PCI devices may need to use hardware configuration files to augment the driver private information. See driver.conf(4) and pci(4) for further details.
SBus
Typical SBus systems consist of a motherboard (containing the CPU and SBus interface logic), a number of SBus devices on the motherboard itself, and a number of SBus expansion slots. An SBus can also be connected to other types of buses through an appropriate bus bridge.
The SBus is geographically addressed; each SBus slot exists at a fixed physical address in the system. An SBus card has a different address depending on which slot it is plugged into. Moving an SBus device to a new slot causes the system to treat it as a new device. See "Persistent Instances" for more information.
The SBus uses polling interrupts. When an SBus device interrupts, the system only knows which of several devices might have issued the interrupt. The system interrupt handler must ask the driver for each device whether it is responsible for the interrupt.
SBus Physical Address Space
Table 2-1 shows the physical address space layout of the Sun UltraTM 2. A physical address on the Ultra 2 consists of 41 bits. The 41-bit physical address space is further broken down into multiple 33-bit address spaces identified by PA(40:33).
Table 2-1 Device Physical Space in the Ultra 2|
PA(40:33) |
33-bit Space |
Usage |
|---|---|---|
|
0x0 |
0x000000000 - 0x07FFFFFFF |
2GB Main memory |
|
0x80 - 0xDF |
Reserved on Ultra 2 |
Reserved on Ultra 2 |
|
0xE0 |
Processor 0 |
Processor 0 |
|
0xE1 |
Processor 1 |
Processor 1 |
|
0xE2 - 0xFD |
Reserved on Ultra 2 |
Reserved on Ultra 2 |
|
0xFE |
0x000000000 - 0x1FFFFFFFF |
UPA Slave (FFB) |
|
0xFF |
0x000000000 - 0x0FFFFFFFF |
System I/O space |
|
|
0x100000000 - 0x10FFFFFFF |
SBus Slot 0 |
|
|
0x110000000 - 0x11FFFFFFF |
SBus Slot 1 |
|
|
0x120000000 - 0x12FFFFFFF |
SBus Slot 2 |
|
|
0x130000000 - 0x13FFFFFFF |
SBus Slot 3 |
|
|
0x1D0000000 - 0x1DFFFFFFF |
SBus Slot D |
|
|
0x1E0000000 - 0x1EFFFFFFF |
SBus Slot E |
|
|
0x1F0000000 - 0x1FFFFFFFF |
SBus Slot F |
Physical SBus Addresses
The SBus has 32 address bits, as described in the SBus Specification. Table 2-2 describes how the Ultra 2 uses the address bits.
Table 2-2 Ultra 2 SBus Address Bits|
Bits |
Description |
|---|---|
|
0 - 27 |
These bits are the SBus address lines used by an SBus card to address the contents of the card. |
|
28 - 31 |
Used by the CPU to select one of the SBus slots. These bits generate the SlaveSelect lines. |
This addressing scheme yields the Ultra 2 addresses shown in Table 2-1. Other implementations may use a different number of address bits.
The Ultra 2 has seven SBus slots, four of which are physical. Slots 0 through 3 are available for SBus cards. Slots 4-12 are reserved. The slots are used in the following way:
-
Slots 0-3 are physical slots that have DMA-master capability.
-
Slots D, E, and F are not actual physical slots, but refer to the onboard direct memory access (DMA), SCSI, Ethernet, and audio controllers. For convenience, these are viewed as being plugged into slots D, E, and F.
Note -Some SBus slots are slave-only slots, such as slot 3 on the SPARCstation1. Drivers that require DMA capability should use ddi_slaveonly(9F) to determine if their device is in a DMA-capable slot. For an example of this function, see "attach()".
SBus Hardware Configuration Files
Hardware configuration files are normally unnecessary for SBus devices. However, on some occasions drivers for SBus devices may need to use hardware configuration files to augment the information provided by the SBus card. See driver.conf(4) and sbus(4) for further details.
VMEbus
The VMEbus supports multiple address spaces. Appropriate entries in the driver.conf(4) file should be made for the address spaces used by the device For DMA devices, the address space that the board uses for its DMA transfers must be known by the driver (this is usually a 32- or 24-bit space).
A VMEbus card has its own address, possibly configurable by jumpers. A VMEbus card has the same address no matter which slot it is plugged into. Changing the address of a VME card causes the system to treat it as a new device.
The VMEbus uses vectored interrupts. When a VMEbus device interrupts, the system can identify which device is interrupting and call the correct device driver directly.
VMEbus Hardware Configuration Files
Most VME devices require hardware configuration files to inform the system that the device hardware may be present. The configuration file must specify the device addresses on the VMEbus and any interrupt capabilities that the device has.
Configuration files for VMEbus devices should identify the parent bus driver implicitly using the class keyword and specifying class "vme." This removes the dependency on the name of the particular bus driver involved, since the driver may be named differently on different platforms. See driver.conf(4) and vme(4) for further details.
ISA Bus
ISA Bus Memory and I/O Space
Two address spaces are provided: memory address space and I/O address space. Depending on the device, registers may appear in one or both of these address spaces. Table 2-3 shows the registers for memory and I/O address spaces in the ISA bus.
Table 2-3 ISA Bus Address Space|
ISA Space Name |
Address Size |
Data Transfer Size |
Physical Address Range |
|---|---|---|---|
|
Main memory |
24 |
16 |
0x0-0xffffff |
|
I/O |
-- |
8/16 |
0x0-0xfff |
Registers can be mapped in memory address space and used by the driver as normal memory (see "Memory Space Access").
Registers in I/O space are accessed through I/O port numbers using separate kernel routines. See "I/O Space Access" for more information.
Hardware Configuration Files
Beginning with the Solaris 7 operating environment, the use of hardware configuration files to provide arguments to probe(9E) on x86 platforms is highly discouraged, since probes can lead to system hangs and resets. Exact device configuration information is maintained by the booting system and is passed to the probe(9E) function.
A separate realmode driver may need to be developed for the booting system. See the Realmode Drivers white paper in the Driver Development Site at http://www.sun.com/developers/driver for information on realmode drivers. Hardware configuration files may be needed on some occasions to augment the information provided by the booting system. See driver.conf(4) and isa(4) for further details.
EISA Bus
Memory and I/O Space
Two address spaces are provided: memory address space and I/O address space. Depending on the device, registers may appear in one or both of these address spaces. Table 2-4 shows the registers for memory and I/O address spaces in the EISA bus.
Table 2-4 EISA Bus Address Space|
EISA Space Name |
Address Size |
Data Transfer Size |
Physical Address Range |
|---|---|---|---|
|
Main Memory |
32 |
32 |
0x0-0xffffffff |
|
I/O |
-- |
8/16/32 |
0x0-0xffff |
Registers can be mapped in memory address space and used by the driver as normal memory (see "Memory Space Access").
Registers in I/O space are accessed through I/O port numbers using separate kernel routines. See "I/O Space Access" for more information.
Hardware Configuration Files
Beginning with the Solaris7 operating envionment, the use of hardware configuration files to provide arguments to probe(9E) on x86 platforms is highly discouraged, since probes can lead to system hangs and resets. Exact device configuration information is maintained by the booting system and is passed to the probe(9E) function.
A separate realmode driver may need to be developed for the booting system. See the Realmode Drivers white paper in the Driver Development Site at http://www.sun.com/developers/driver for information on realmode drivers. Hardware configuration files may be needed on some occasions to augment the information provided by the booting system. See driver.conf(4) and eisa(4) for further details.
MCA Bus
Memory and I/O Space
Two address spaces are provided: memory address space and I/O address space. Depending on the device, registers may appear in one or both of these address spaces.
Table 2-5 MCA Address Space|
MCA Space Name |
Address Size |
Data Transfer Size |
Physical Address Range |
|---|---|---|---|
|
Main Memory |
32 |
32 |
0x0-0xffffffff |
|
I/O |
-- |
8/16/32 |
0x0-0xfff |
Registers can be mapped in memory address space and used by the driver as normal memory (see "Device Memory Mapping").
Registers in I/O space are accessed through I/O port numbers using separate kernel routines. See "I/O Space Access") for more information.
Hardware Configuration Files
Hardware configuration files are normally unnecessary for MCA devices. However, on some occasions drivers for MCA devices may need to use hardware configuration files to augment the information provided by the MCA card. See driver.conf(4) and mca(4) for further details.
- © 2010, Oracle Corporation and/or its affiliates