2    Configuring the VMEbus for Alpha VME Systems

This chapter explains how to configure the VMEbus for OEM platforms running Tru64 UNIX. The chapter provides an overview followed by sections that address groups of platforms based on their VMEbus adapter type:

• VMEbus support overview (Section 2.1)

• Configuring VIP/VIC-based Alpha VME SBCs (Section 2.2)

• Configuring UNIVERSE II-based Alpha VME SBCs (Section 2.3)

2.1    VMEbus Support Overview

The Tru64 UNIX operating system includes a generic VMEbus interface layer that provides customers with a consistent interface to VMEbus devices across Alpha workstation and server platforms and Alpha VME single-board computers (SBCs).

The operating system supports the following PCI/VMEbus adapters:

• UNIVERSE II PCI64-to-VME64 adapter

• VIP/VIC PCI32-to-VME64 adapter

• DWP64 PCI32-to-VME64 adapter

• DWPVC PCI32-to-VME32 adapter

Alpha VME SBCs provide an integrated PCI/VMEbus adapter: either VIP/VIC or UNIVERSE II. The DWP64 and DWPVC adapters are provided in layered product kits for use with Alpha workstation and server platforms.

For information about the VMEbus-based systems supported by the operating system, see the Tru64 UNIX Software Product Description (SPD).

This chapter provides information about configuring the VMEbus on the Alpha VME family of SBCs. To configure a VMEbus backplane (vb) network with Alpha VME SBCs in the same backplane communicating as network nodes, see Chapter 3.

To write VMEbus device drivers, you must obtain the Tru64 UNIX Device Driver Kit (DDK), which is available separately from the base operating system. The DDK provides a detailed VMEbus device driver example that you can run on the Alpha VME SBCs.

To write VMEbus device drivers for Alpha workstation and server platforms with DWP64 or DWPVC adapters, you must have the associated adapter driver software and documentation in addition to the DDK. Be sure to check for the required processor and hardware configurations. For more information about the DWP64 and DWPVC adapters, see the PCI32/VME64 Adapter Driver SPD and the PCI/VME Adapter Driver SPD.

2.2    Configuring VIP/VIC-Based Alpha VME SBCs

This section describes how to set up VIP/VIC-based Alpha VME systems for use on the VMEbus, including how to modify attributes of the vba_vipvic kernel subsystem.

VMEbus setup allows you to run the operating system on the following VIP/VIC-based AXPvme and Alpha VME systems:

• AXPvme single-board computers (SBCs)

• Alpha VME 4/224 and 4/228 SBCs

• Alpha VME 5/352 and 5/480 SBCs

• Alpha VME 2100 system

For information about installing the operating system on the listed systems, see the Installation Guide.

For information about setting up UNIVERSE II-based Alpha VME systems for use on the VMEbus, see Section 2.3.

This section addresses the following topics relating to the use of the VMEbus on the listed systems:

• Configuring the vba_vipvic subsystem (Section 2.2.1)

• Configuring VMEbus A32 and A24 address spaces (Section 2.2.2)

• Configuring the VMEbus A16 address space (Section 2.2.3)

• Configuring VMEbus interrupts (Section 2.2.4)

• Using VMEbus hardware byte-swapping modes (Section 2.2.5)

• Sharing memory between big endian and little endian processors (Section 2.2.6)

• Performing VMEbus slave block transfers (Section 2.2.7)

• Performing VMEbus master block transfers with local DMA (Section 2.2.8)

• Using the realtime interrupt-handling routine rt_post_callout (Section 2.2.9)

2.2.1    Configuring the vba_vipvic Subsystem

This section describes how to configure the vba_vipvic kernel subsystem in order to prepare VIP/VIC-based AXPvme and Alpha VME systems for use on the VMEbus.

You configure the VIP/VIC adapter by examining the default (or current) attributes supplied for the vba_vipvic subsystem, determining which attributes (if any) you want to change, then modifying the /etc/sysconfigtab file on your machine. After modifying /etc/sysconfigtab, you must shut down and reboot the system.

Note

Do not directly edit /etc/sysconfigtab. Instead, use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. It is recommended that you maintain private sysconfigtab file fragments for vba_vipvic attributes and use sysconfigdb switches to add (-a -f), delete (-d), or merge (-m -f) vba_vipvic attribute values. The example in Section 3.6 illustrates this approach. The sys_attrs(5) reference page provides additional guidelines for editing kernel subsystem attributes. You must always reboot after changing vba_vipvic subsystem attributes.

Common modifications to the vba_vipvic subsystem default attributes are to reconfigure the A32, A24, and A16 address spaces. For example, you could use sysconfigdb to edit the following modifications into /etc/sysconfigtab:

vba_vipvic:
        A32_Base = 0x10000000
        A32_Size = 0x08000000
        A24_Base = 0x00A00000
        A24_Size = 0x200000
        A16_Base = 0x00000000

In this example, the A24 inbound DMA window base address is modified from the default 0x00C00000 to 0x00A0000; the A24 window size from the default 4 MB to 2 MB; and the A16 interprocessor communication base address from the default 0x00000100 to 0x00000000.

You can modify values for the following VIP/VIC adapter attributes; each list item corresponds to a later subsection:

VMEbus request level (Section 2.2.1.1)

VIC arbitration mode (Section 2.2.1.2)

VMEbus fairness timer value (Section 2.2.1.3)

Local bus and VMEbus timeout periods (Section 2.2.1.4)

VMEbus release mode (Section 2.2.1.5)

System controller VMEbus resets (Section 2.2.1.6 and Section 2.2.1.7)

VIC master write posting (Section 2.2.1.8)

VMEbus DMA interleave gap (Section 2.2.1.9)

VMEbus DMA read limit (Section 2.2.1.10)

VMEbus DMA write limit (Section 2.2.1.11)

DMA method (hardware or emulated) for SMP systems (Section 2.2.1.12)

You can also modify the following values for the A32, A24, and A16 address spaces that the VMEbus hardware architecture defines; each list item corresponds to a later subsection:

A32 and A24 overlapping address configuration (Section 2.2.2.1)

A32 and A24 DMA inbound window sizes (Section 2.2.2.2)

A32 DMA inbound window base address (Section 2.2.2.3)

A24 DMA inbound window base address (Section 2.2.2.4)

A16 base for interprocessor communication facilities (Section 2.2.3)

Table 2-1 lists the defaults supplied for various VMEbus parameters. The default values specified should provide proper VMEbus operation for most applications. Be careful when modifying these values; not all adapters support all fields.

Table 2-1:  VIP/VIC VMEbus Adapter Defaults

Table 2-2 lists VMEbus interrupt parameters and their initial defaults. These defaults are later overwritten by system priority level (SPL) values supplied by the platform. See the SPL values listed in Table 2-3, or query the values at run time using the command sysconfig -q vba_vipvic.

Table 2-2:  VIP/VIC VMEbus Interrupt Initial Defaults

2.2.1.1    Specifying the VMEbus Request Level

You can specify one of the following values for the VMEbus request level (parameter VME_Br_lev). The value is stored in the VIC64 Arbiter/Requester Configuration Register (ARCR).

2.2.1.2    Specifying the VIC Arbitration Mode

You can specify one of the following values for the VMEbus arbitration mode (parameter VIC_Arb_Mode). The VMEbus arbitration mode is stored in the VIC64 Arbiter/Requester Configuration Register (ARCR). This parameter is applicable only when the VMEbus adapter is configured to be the system controller.

2.2.1.3    Specifying the VMEbus Fairness Timer Value

You can specify one of the following values for the Arbiter/Requester fair request timeout (parameter VME_Fair_Req). The fair request timeout value is stored in the VIC64 Arbiter/Requester Configuration Register (ARCR).

2.2.1.4    Specifying Bus Timeout Periods

You can specify one of the following values for the local bus timeout period (parameter VIC_Loc_Bus_To) and for the VMEbus timeout period (parameter VME_Bus_To). Each value is stored in the VIC64 Transfer Timeout Register (TTR). The local bus timeout period must be shorter than the VMEbus timeout period.

2.2.1.5    Specifying the VMEbus Release Mode

You can specify one of the following values for the release mode (parameter VIC_Rel_Mode). The release-mode value is stored in the VIC64 Release Control Register (RCR).

2.2.1.6    Specifying System Controller VMEbus Resets

You can specify one of the following values to indicate whether or not the adapter should issue VMEbus resets if it is the system controller (parameter VIC_Syscon).

For AXPvme SBCs and Alpha VME 4/nnn and 5/nnn SBCs, in addition to specifying a value from this list, you must set the configuration switches to indicate whether or not the SBC is the VMEbus system controller. See the SBC's installation guide for information on setting the module configuration switches.

The Alpha VME 2100 adapter is always the VMEbus system controller. There are no module configuration switches to disable it from being the system controller.

The VMEbus backplane must have only one system controller. The system controller must be electrically the first module in the VMEbus backplane and in most systems must be in the first VMEbus slot.

The values specified interact with the VMEbus initialization code to determine whether a VMEbus reset is issued when the VMEbus adapter is being configured. If the value is set to 1 and the system being booted is the system controller, as determined by the VMEbus initialization code, a VMEbus reset is issued. If you do not want a VMEbus reset issued during VMEbus adapter configuration, set the value to 0 (zero). These values pertain only to the system controller.

If the system controller is configured to issue a VMEbus reset during adapter initialization, and other processor modules are installed in the VMEbus backplane, boot the system controller first to allow devices and processor modules to perform their bus reset actions.

2.2.1.7    Special Considerations for VMEbus Resets

The system controller should always be the initiator of VMEbus resets. However, under certain error conditions, other VMEbus adapter modules may invoke a VMEbus reset. Modules installed in the VMEbus backplane react to bus resets differently. Some modules, if configured, perform a module reset. Some may have their VMEbus interface reset to a power-up state without notification to the operating system. This could leave the VMEbus adapters in an unconfigured state, cause unwanted effects to the operating system and its device drivers, and cause VMEbus errors to occur. Other VMEbus adapters on the VMEbus may accept VMEbus resets and attempt to reconfigure themselves to the hardware context they were running before the bus reset occurred. However, device drivers expecting interrupts may not receive them and I/O hardware operations may be canceled by the VMEbus reset without notification to the device driver. There is also a potential for data corruption to occur when the VMEbus adapter is reset during an I/O operation.

It is recommended that the system controller be the initiator of VMEbus resets during adapter initialization. If the system controller is not controlled by a processor, then a power-up sequence should cause all VMEbus adapters and devices to be reset. All modules on the VMEbus should perform a module reset upon detection of a bus reset. VMEbus adapters that are not the system controller and that are running an operating system should be shut down in an orderly fashion prior to the system controller being booted. These VMEbus adapters should be rebooted after the system controller has been booted, providing that the system controller is to be used and controlled by a processor.

For Alpha VME 2100 systems, the VMEbus adapter can be the initiator of VMEbus resets only. Upon receipt of a bus reset, its VMEbus interface (VIC64) is reset. The reset state of the VMEbus interface (VIC64) is not the VMEbus adapter's configured state. The operating system and device drivers are not notified that a bus reset has occurred. If the adapter is accessed or if an I/O operation is invoked following a bus reset, the access may result in an adapter error, misoperation, or system crash.

For AXPvme SBCs and Alpha VME 4/nnn and 5/nnn SBCs, it is recommended that nodes that are not the system controller have their module configuration switch 3 set to Closed (resets the SBC module in response to a VMEbus reset signal). When the VMEbus is reset, and the module switch is set to accept a VMEbus reset, nonsystem controller modules take a boot action and are reset to a powered state.

If the SBC module configuration switch 3 is set to Open (does not reset the SBC module in response to a VMEbus reset signal), the VMEbus adapter software will receive a VMEbus reset interrupt upon detection of a bus reset. The VMEbus reset signal initializes the VMEbus adapter (VIC64) to its power-up state. The VMEbus reset interrupt service interface displays the following message on the console terminal:

vba0 reset_inter:  VMEbus reset detected

The interrupt service interface then initializes the VMEbus adapter to its defaults and enables any previously enabled interrupt enable bits.

Do not set the SBC module configuration switch 3 to Open without considering the following side effects of receiving a VMEbus reset: device drivers expecting interrupts may not receive them and I/O hardware operations may be canceled by the VMEbus reset without notification to the device drivers. There is potential risk of data corruption depending upon I/O activity at the time a bus reset occurred.

2.2.1.8    Specifying VMEbus Master Write Posting

Master write posting is not currently supported. Do not change the value from the default of 0 (zero) or unpredictable results may occur.

2.2.1.9    Specifying the VMEbus DMA Interleave Gap

You can specify one of the following values for the DMA interleave gap (parameter VIC_DMA_Intrlv), which is the time period between master block transfer (MBLT) DMA bursts. The DMA interleave gap value is stored in the VIC64 Block Transfer Control Register (BTCR) at the start of a master block transfer DMA. This parameter is applicable only when you use the VMEbus adapter's hardware DMA engine to perform the DMA.

Caution

You must not specify the value 0 (zero) if D64 master block transfers are to be performed. Unpredictable errors and possible data corruption may result if you specify 0 (zero) with D64 transfers.

During the DMA interleave gap, stalled or new programmed I/O (PIO), VMEbus IACK cycles, or slave DMAs may obtain the bus to perform the required I/O operation. The VIC64 is enabled for dual paths to allow these I/O operations to occur during the DMA interleave gap. Changing this parameter arbitrarily may cause unwanted side effects.

Decreasing the value from the default increases DMA throughput. However, as the number approaches 0 (zero), outstanding PIO operations, VMEbus IACKs, and slave DMAs may be held off from obtaining the bus until the DMA in progress is completed. These operations might have occurred during the DMA interleave gaps if the default value had been used.

Specifying a small DMA interleave gap may result in PCI retry timeouts, poor PIO performance, increased interrupt response time, other PCI transactions being held off, and possible system time loss. Beware of these side effects when specifying a new value for the DMA interleave gap.

2.2.1.10    Specifying Limits on VMEbus DMA Reads

You can specify one of the following values to enable or disable an 8 KB limit on DMA read operations (parameter Lmt_DMA_Rd). Placing an 8 KB limit on DMA reads can enhance throughput when the bus is busy. Transfers relinquish the bus after each 8 KB or less.

2.2.1.11    Specifying Limits on VMEbus DMA Writes

You can specify one of the following values to enable or disable an 8 KB limit on DMA write operations (parameter Lmt_DMA_Wrt). Placing an 8 KB limit on DMA writes can enhance throughput when the bus is busy. Transfers relinquish the bus after each 8 KB or less.

2.2.1.12    Specifying the DMA Method for SMP

You can specify one of the following values to enable or disable use of the hardware DMA engine on an SMP system (parameter Frce_Hw_DMA). Note that in an SMP system, you would enable use of the hardware DMA engine only if the system was known to be quiescent, with no other PIO, DMA, or interrupt activity occurring on the bus.

2.2.2    Configuring VMEbus A32 and A24 Address Spaces

As part of configuring the vba_vipvic kernel subsystem, you can configure the VMEbus 32-bit address space (A32) and 24-bit address space (A24) for your system. A32 and A24 space are used for direct memory access (DMA) inbound windows.

The A32 space has a maximum size of 4 GB and can be partitioned into 32 128 MB windows. You can further partition each 128 MB window in increments as small as 16 MB. Valid window segments are 16, 32, and 64 MB.

The A24 space has a maximum size of 16 MB, and the base address is always zero (0x00000000). This means that you can partition the address space but cannot move it. The default window size is 4 MB and the base address for a window must be a multiple of the window size. The default inbound window is the top 4 MB of the 16 MB space.

You can specify whether the A24 and A32 addresses can reside within the same addressing range or whether they must be unique.

2.2.2.1    Specifying A32 and A24 Address Space Overlapping

Read this section if the A32 direct memory access (DMA) inbound window will be configured with a base address of zero (0x00000000), overlapping the A24 address space. A24 inbound windows are always configured within the first 16 MB of the 4 GB VMEbus address space.

Typically, VMEbus A24 and A32 address spaces overlap each other such that addresses in each address space are unique to that address space. As an example, address 0x200 in A32 address space is not the same address as 0x200 in A24 address space. This is the default configuration, selected if you leave the A24_A32_Ovrlap parameter at its default value of 1.

You can configure some VMEbus devices to recognize the same VMEbus address in both A24 and A32 address spaces. These devices treat the two address spaces as a single entity. Consult the VMEbus hardware device manuals to determine if any devices installed on the VMEbus follow this model. If so, you must configure the autoconfiguration software to disallow A32 DMA allocations within the first 16 MB of VMEbus address space. If you do not do this, an A32 direct memory access to the first 16 MB of VMEbus address space by another VMEbus device may not only select the AXPvme or Alpha VME module but also select the device that treats the address spaces as a single entity.

Configure the first 16 MB of VMEbus address space as a single entity by setting the A24_A32_Overlap parameter to 0 (zero).

The values for overlapping and unique address spaces are as follows. These values are valid only when the A32 and A24 address spaces are configured to overlap each other; that is, when the A32 base address equals zero (0x00000000).

2.2.2.2    Configuring A32 and A24 Window Sizes

You can specify the DMA inbound window size for the A32 address space (parameter A32_Size) and the A24 address space (parameter A24_Size).

If you specify an invalid base address in relation to a window size, the autoconfiguration code adjusts the base address to match the window size. The base address is adjusted downward to the next appropriate boundary for the window size.

The window size values are as follows:

2.2.2.3    Specifying the A32 Base Address

You specify the A32 base address using the A32_Base parameter. The following table lists the values used for partitioning 128 MB windows in the A32 address space. Note that the base value is contained in bits 24 through 31, with bits 27 through 31 indicating the window and bits 24 through 26 indicating the partition size.

2.2.2.4    Specifying the A24 Base Address

You specify the A24 base address using the A24_Base parameter. The following table lists the base address values for windows in the A24 address space. The base address is stored in bits 16 through 23. The table has been truncated for the smaller window sizes.

2.2.3    Configuring the VMEbus A16 Address Space

As part of configuring the vba_vipvic kernel subsystem, you can configure the VMEbus 16-bit address space (A16) for your system. A16 space is used for interprocessor communication and to communicate with A16 VMEbus devices.

The A16 space has a maximum size of 64 KB and runs from VMEbus address 0000 hexadecimal to FFFF hexadecimal. You can configure the VMEbus Interprocessor Communication Facilities (ICF) of the AXPvme SBC, Alpha VME 4/nnn or 5/nnn SBC, or Alpha VME 2100 system on any 256-byte boundary within the VMEbus A16 address space. The default base address (parameter A16_Base) is 0x00000100. The mask value (parameter A16_Mask) must be left at zero (0x00000000).

2.2.4    Configuring VMEbus Interrupts

This section addresses VMEbus interrupt request levels and how to configure VMEbus interrupts in the software.

2.2.4.1    VMEbus Interrupt Request Levels

Table 2-3 lists the system priority levels (SPLs) at which VMEbus and VMEbus adapter interrupt requests are delivered to the operating system and device drivers. You can query your system's VMEbus SPLs at run time by issuing the command sysconfig -q vba_vipvic.

Table 2-3:  VIP/VIC VMEbus Interrupt Request Levels

The Alpha VME 4/nnn and 5/nnn SBCs do not support autovector requests. The Alpha VME 2100 system does not support autovector or VMEbus reset interrupt requests.

As Table 2-3 indicates, AXPvme and Alpha VME SBCs generate interrupt requests that higher-level interrupt requests can preempt, while Alpha VME 2100 interrupt requests are all delivered at the same SPL and cannot be preempted.

On the AXPvme and Alpha VME SBCs, device drivers must use the rt_post_callout routine for interrupts delivered at SPLDEVRT. Interrupt requests for which this is needed are VMEbus IRQ7, Autovector IRQ7, and any of the four module switch interrupts. Device drivers written for the SBCs that use the rt_post_callout routine will also run on the Alpha VME 2100 system without modifications.

Note

VMEbus device drivers written for Alpha VME 2100 systems, or for other platforms that deliver VMEbus interrupts at a single SPL, may be affected when run on the AXPvme or Alpha VME SBC platforms. If these device drivers are using SPLs to protect common resources between thread and interrupt service interfaces, the preempted interrupts of the SBC systems may have unwanted effects on the drivers. If these device drivers are servicing interrupts for VMEbus IRQ7, Autovector IRQ7, or module switch interrupts, then the drivers must be modified to use the rt_post_callout routine. Device drivers cannot invoke normal thread wakeup mechanisms at SPLDEVRT.

2.2.4.2    Setting VMEbus Interrupt Vector Parameters

You specify vectors and interrupt requests (IRQs) for a device driver using the Vector and Bus_Priority fields of a VBA_Option entry in the /etc/sysconfigtab file or in a sysconfigtab file fragment.

Device drivers are passed this information in the controller structure elements ivnum and bus_priority.

VMEbus interrupt vectors 24 to 255 are available to device drivers. Vectors 0 to 23 are reserved by the VMEbus adapter. When you specify a vector to the Vector field of VBA_Option, you must also use the Bus_Priority field to specify an IRQ. Valid IRQ specifications are values 1 through 7. These values correspond to VMEbus levels IRQ1 through IRQ7.

Note that if a VMEbus device uses an IRQ, that same IRQ cannot be used for autovectored interrupts.

See the Autoconfiguration Support section of Writing VMEbus Device Drivers (available in the Device Driver Kit) for an example of adding and enabling VMEbus interrupts. See the vme_handler_info structure in Writing VMEbus Device Drivers for interrupt handler information.

2.2.4.3    Specifying Autovector Interrupt Vectors

The Alpha VME 4/nnn, 5/nnn, and 2100 platforms do not support autovectors.

VMEbus devices of the type Release of Register Access (RORA) use autovectors. RORA devices are incapable of presenting a status/ID vector in the manner of Release On Acknowledge (ROAK) VMEbus devices.

RORA devices present an interrupt request to the system at a specified VMEbus IRQ level. Upon receipt of the interrupt request, the system provides a system-defined status/ID vector and dispatches it to the interrupt service interface installed for the autovector. The device driver is responsible for dismissing the RORA device's interrupt request by performing a read or write access to the device. See the hardware manual for the RORA device to determine what type of access is needed to dismiss the interrupt request.

To select an autovector, use the Vector and Bus_Priority fields of VBA_Option. Specify a vector value of 0 (zero) and an IRQ value of 1 through 7, corresponding to VMEbus levels IRQ1 through IRQ7.

If an IRQ is used for an autovector, the same IRQ cannot be used for VMEbus interrupt vectors.

2.2.4.4    Specifying Module Switch Interrupt Vectors

Specify one of the following vectors in the Vector field of VBA_Option to select the module switch interrupt you want. Use the Bus_Priority field to specify 7 as the IRQ level.

Module switch interrupt vectors allow a module to issue an interrupt to itself or to another module. The autoconfiguration software provides control and status registers (CSRs) for use in module switch interrupts. You can specify two CSRs in a VBA_Option entry in the /etc/sysconfigtab file or in a sysconfigtab file fragment. At boot time, the system searches for the specified CSRs.

The autoconfiguration software performs the appropriate bus mapping and provides io_handle_t values in the addr and addr2 members of the driver's controller structure. The addr argument is passed to the driver's probe routine, while the addr2 value must be obtained from the addr2 member of the controller structure.

For example, the following VBA_Option entry specifies a CSR for the base address of the A16 Interprocessor Communication Facilities (ICF). The module switch 1 CSR is an offset from this A16 address.

VBA_Option = Csr1 - 0x100, ..., Vector - 0x1150, Bus_Priority - 7, ...
 

The driver structure allows you to specify the size, address type, and swap mode for the CSRs. For example, the following members in a driver structure indicate that the first CSR has a size of 256 bytes, is in the A16 address space, and is set to noswap mode:

int     addr1_size      256
int     addr1_atype     VME_A16_SUPER_ACC | VME_BS_NOSWAP

For more information, see the Device Driver Kit manuals Writing Device Drivers and Writing VMEbus Device Drivers, especially the sections on the addr and addr2 members of the controller structure and on the addr1_size, addr1_atype, addr2_size, and addr2_atype members of the driver structure.

In addition, you can use the vba_map_csr routine to provide module switch interrupts. After using the vba_map_csr routine to create an I/O handle, you write to an address derived from the base address plus an offset. Two write operations are performed, one signifying a clear and one a set. The following code fragment shows how the I/O handle is created:

io_handle_t     ioh;           /* Define type of ioh */
vme_addr_t      A16base=0x100; /* Base CSR address */
ioh = vba_map_csr(ctlr, A16base, 256,
                 (VME_A16_SUPER_ACC |
                  VME_BS_NOSWAP));

The following code fragment shows how the module switch interrupts are issued:

write_io_port(ioh+0x22, 1, 0, 0)  /* Write to A16 base address
                                     plus the offset to clear
                                     module switch 1 */
mb();
write_io_port(ioh+0x23, 1, 0, 0)  /* Write to A16 base address
                                     plus the offset to set
                                     module switch 1 */
mb();

2.2.4.5    Specifying Global Switch Interrupt Vectors

Global switch interrupts are not currently supported.

2.2.5    Using VMEbus Hardware Byte-Swapping Modes

Alpha processors are little endian, while the VMEbus is big endian. The default byte-swapping mode, VME_BS_NOSWAP, causes the transfer of bytes between Alpha processors and the VMEbus to be arranged correctly. If, however, a 16-bit or 32-bit number is needed in a VMEbus register, the VME_BS_NOSWAP mode rearranges the bytes within the transfer such that the bytes are reversed in significance. Two other modes are provided to handle these situations: VME_BS_BYTE and VME_BS_LWORD. A third mode for swapping words within longwords, VME_BS_WORD, is not portable across VMEbus adapters and is provided for convenience. The definitions for these modes are in the io/dec/vme/vbareg.h file. The flags for these modes are used in vba_map_csr, in dma_map_alloc or dma_map_load, and in the driver structure.

VME_BS_NOSWAP mode provides a hardware mechanism for data coherency for byte-data transfers from Alpha processors (little endian) to the VMEbus (big endian). The address of any byte as seen on the two buses remains the same. Block transfers of byte information use 16- or 32-bit transfers. The transfer sizes are 8-, 16-, or 32-bits of byte information. Noswap-mode byte addressing is as follows:

VME_BS_BYTE mode provides a hardware mechanism for data coherency for 16-bit data transfers across the VMEbus, such as loading a 16-bit counter on a VMEbus device. In this mode, bytes within words are swapped. For portability, use only 16-bit aligned transfers. Byte swap-mode byte addressing is as follows:

VME_BS_WORD mode provides a hardware mechanism for swapping words within longwords on certain VMEbus adapters. This mode is not portable across VMEbus adapters; on other VMEbus adapters, byte swapping may be dependent on data size. For AXPvme and Alpha VME platforms, system word swap-mode byte addressing is as follows:

VME_BS_LWORD mode provides a hardware mechanism for data coherency for 32-bit data transfers across the VMEbus, such as loading a 32-bit VMEbus address register. In this mode, bytes within words are swapped and words within longwords are swapped. The transfer size is 32 bits only. For portability, use only 32-bit transfers. Longword swap-mode byte addressing is as follows:

2.2.6    Sharing Memory Between Big Endian and Little Endian Processors

In a shared memory environment, where packed data structures in common memory are shared between an Alpha processor (little endian) and a big endian processor, software byte swapping is required to arrange bytes properly for 16- or 32-bit quantities (such as 16-bit counter values or 32-bit VMEbus address values).

The following combination is recommended: VME_BS_NOSWAP with software byte swapping on nonbyte data for the Alpha processor; and no swapping on the big endian processor.

You could implement software swapping with read/write macros that perform the swap with the following code. The purpose here is to provide code that would run on both little endian and big endian machines that have shared memory.

 #define read_word/long(iohandle,data)                     /
         data = read_io_port(iohandle,sizeof(word/long),0);/
 #ifdef LITTLEENDIAN                                       /
         swap_xx(data);                                    /
 #else /* BIGENDIAN */                                     /
 #endif
 #define write_word/long(iohandle,data)                    /
 #ifdef LITTLEENDIAN                                       /
         swap_xx(data);                                    /
 #else /* BIGENDIAN */                                     /
         write_io_port(iohandle,sizeof(word/long),0,data); /
 #endif

2.2.7    Performing VMEbus Slave Block Transfers

The AXPvme and Alpha VME platforms are configured during adapter initialization to accept slave block transfers (SBLTs) with data widths of D16, D32, or D64. After the SBC has mapped its memory onto the VMEbus by using the dma_map_alloc and dma_map_load routines, no other user interaction is needed. For information on calling the dma_map_alloc and dma_map_load routines, see the corresponding reference pages in the Device Driver Kit (available separately from the base operating system).

Memory must be mapped to the VMEbus prior to D64 slave access.

Access to memory must coincide with the appropriate access mode. If you specify supervisory-mode access when memory is mapped, memory accesses must use supervisory mode. If you specify user-mode access, both supervisory and user access are allowed.

2.2.8    Performing VMEbus Master Block Transfers with Local DMA

The VMEbus interfaces for the AXPvme and Alpha VME platforms provide a block-mode DMA engine. This DMA engine is capable of transferring up to 64 KB of data without processor intervention, in VMEbus data widths of D16, D32, or D64.

The DMA engine transfers data from the VMEbus to system memory (read) or from system memory to the VMEbus (write). The hardware interface handles the segmentation of the transfer. This ensures that the VMEbus specification is not violated in relation to crossing VMEbus 256-byte boundaries for D16 and D32 or 2-KB boundaries for D64.

The DMA engine is configured to give up the VMEbus during the transfer and to rearbitrate for the VMEbus again to continue the DMA. The time between when the DMA engine gives up the bus and rearbitrates for the bus is called the interleave period. During the interleave period, single-cycle VMEbus cycles, receipt of slave block transfers (SBLTs), or other operations may be performed.

The master block transfer (MBLT) hardware interface presents address modifiers of user block or supervisory block to the VMEbus, based on parameters passed in the software programming interface. The device or system on the VMEbus must be able to interpret these address modifiers; otherwise, bus errors may occur.

You can use the MBLT hardware interface to:

• Transfer data to and from those VMEbus devices that do not have their own DMA engine

• Move data between VMEbus device memory and system memory

• Transfer data to and from other systems that have their memory mapped to the VMEbus

The MBLT hardware interface supports DMA block-mode transfers to and from VMEbus A24 and A32 address space only.

2.2.8.1    Routines for Master Block-Mode Transfers

To use master block transfers (MBLTs) with the local hardware DMA engine, you must invoke the following routines and supply specific flag values:

vba_set_dma_addr

dma_map_alloc

dma_map_load

vba_dma

dma_map_unload

dma_map_dealloc

For information on calling these routines, see the corresponding reference pages in the Device Driver Kit (available separately from the base operating system).

The flag values DMA_IN and DMA_OUT have specific meaning for VMEbus support with respect to the dma_map_alloc, dma_map_load, and vba_dma routines. These flags indicate to the low-level VMEbus dma_map_alloc, dma_map_load, and vba_dma routines that the MBLT hardware DMA engine is to be used and the direction of the transfer.

Specifying DMA_IN implies a read from the VMEbus to system memory. Specifying DMA_OUT implies a write from system memory to the VMEbus. You use the vba_set_dma_addr routine to pass the flag values and the VMEbus address at which the transfer is to occur.

The VMEbus block-mode DMA engine on the VMEbus adapter is a single entity that must be shared among various device drivers. Specifying DMA_SLEEP causes the device driver to block in the vba_dma routine if the DMA engine is already being used. If DMA_SLEEP is not specified and the DMA engine is being used, vba_dma returns an error.

The following sample code shows how to invoke the MBLT hardware DMA engine for a block-mode read operation. The code uses a VMEbus transfer width of D32 to invoke a 256 KB transfer from VMEbus address A24 0x400000 to system memory. The code also allocates resources to handle transfers up to 1 MB in size. This allows dma_map_load and vba_dma to be invoked multiple times with varying size buffers. You can change the code to perform writes by substituting DMA_OUT for DMA_IN.

struct controller *ctlr;
vme_addr_t        vme_addr = 0x40000;
unsigned long     max_bc = (1024*1024);
unsigned long     rtn_bc;
char              *buffer;
unsigned long     buffer_bc = (1024 * 256);
sglist_t          dma_handle = (sglist_t)NULL;
vme_atype_t       flags = (VME_A24_UDATA_D32|DMA_IN|DMA_SLEEP);
int               rtn_flags;
/*
 *  Allocate a buffer (256 KB) to be used for the transfer
 */
MALLOC(buffer,(char *),buffer_bc,M_DEVBUF,M_WAITOK);
/*
 *  Specify a VMEbus address of 0x40000
 *  Specify flags
 *     A24 address space
 *     User mode
 *     Select DMA engine for a read (DMA_IN) and
 *       wait for DMA engine (DMA_SLEEP)
 */
rtn_flags = (int)vba_set_dma_addr(ctlr,flags,vme_addr);
/*
 *  Allocate DMA resources for up to 1 Mbyte transfer
 *    Specify flags returned from vba_set_dma_addr() above
 *    The return value from dma_map_alloc() should equal max_bc
 */
rtn_bc = dma_map_alloc(max_bc,ctlr,&dma_handle,rtn_flags);
/*
 *  Call dma_map_load() to load the resources for the
 *  DMA block-mode engine
 *    Specify the dma_handle returned from dma_map_alloc()
 *    Specify flags returned from vba_set_dma_addr()
 *    The return value from dma_map_load() should equal buffer_bc
 */
rtn_bc = dma_map_load(buffer_bc,
                      (vm_offset_t)buffer,
                      0,
                      ctlr,
                      &dma_handle,
                      0,
                      rtn_flags);
/*
 * Call vba_dma() to start up and monitor the VME adapter's block-mode
 *   DMA engine. Specify the dma_handle returned from dma_map_alloc.
 *   The return value from vba_dma() is the actual bytes transferred.
 *   This value should be the same as value buffer_bc. If not, then
 *   an error was detected during the transfer.
 */
rtn_bc = vba_dma(ctlr,dma_handle);
/*
 *  Unload and free DMA resources
 */
dma_map_unload(0,dma_handle)
dma_map_dealloc(dma_handle)

2.2.8.2    Restrictions on VMEbus Master Block Transfers

The following restrictions apply to using master block transfers (MBLTs) on the Alpha VME and AXPvme platforms. Failure to adhere to these restrictions may result in data loss during DMA transfers. These restrictions are listed by DMA transfer data width.

• D16, D32, and D64 restrictions

  The VMEbus address and the memory address must be longword aligned (quadword aligned for D64), and the lowest 8 address bits [7:0] must match exactly.

  The requested byte count must be in multiples of the data size (multiples of 2, 4, and 8 for D16, D32, and D64, respectively).

• Further D64 restrictions

  If the VMEbus address is aligned on a 2 KB boundary, the memory address must also be aligned on a 2 KB boundary. This restriction will be removed in a future release of the operating system.

Note that you can use the valloc function to allocate memory aligned to a page boundary, as described in the valloc(3) reference page.

For the best DMA performance, the VMEbus address and the memory address should be aligned to a 256-byte boundary for D16 and D32 DMA transfers, or to a 2048-byte boundary for D64 DMA transfers.

The Alpha VME 2100 system in an SMP environment emulates DMA transfers using PIO operations instead of using an MBLT hardware DMA engine. The VMEbus adapter on this system requires three I/O accesses to be atomic to start the DMA engine. These I/O operations cannot be guaranteed to be atomic in an SMP environment. Uniprocessor systems use the MBLT hardware DMA engine.

2.2.9    Using the Realtime Interrupt-Handling Routine rt_post_callout

Interrupt service interfaces (ISIs) executing at SPLDEVRT (SPL 6) must not call kernel routines directly. The rt_post_callout routine allows the calling process to defer execution of a function until a time when kernel routines can be invoked. The function invoked by rt_post_callout runs at an elevated SPL and is subject to the same restrictions as an ISI.

The syntax for the function invoked by rt_post_callout is as follows:

int (*function)(),
long arg1,
long arg2 );

The parameters for the rt_post_callout routine are as follows:

If rt_post_callout is called again with the same function and arguments specified, then the duplicate invocation is dismissed before the first invocation has executed.

The following example is for an interrupt service interface (ISI) that runs at SPLDEVRT:

rt_dev_intr(unit)
        int unit;
{
 register struct rt_softc *sc = rt_softc[unit];
 rt_post_callout(user_wakeup_interface,   /* User wakeup function */
                 (long) &sc->error_recovery_flag, /* Event to wake*/
                 (long) NULL);            /* Unused argument      */
 return;
}

The following example shows a user-written function to wake up an event called by the rt_post_callout routine:

void user_wakeup_interface ( arg1, arg2 )
long arg1;
long arg2;
{
   thread_wakeup( (vm_offset_t) arg1);
}

2.3    Configuring UNIVERSE II-Based Alpha VME SBCs

This section describes how to set up UNIVERSE II-based Alpha VME systems for use on the VMEbus, including how to modify attributes of the vba_univ kernel subsystem.

VMEbus UNIVERSE II setup allows you to run the operating system on UNIVERSE II-based Alpha VME systems. For information about installing the operating system on these systems, see the Installation Guide.

For information about setting up VIP/VIC-based Alpha VME systems for use on the VMEbus, see Section 2.2.

This section addresses the following topics relating to the use of the VMEbus on UNIVERSE II-based Alpha VME systems:

• Configuring the vba_univ subsystem (Section 2.3.1)

• Configuring PCI-to-VME address spaces (Section 2.3.2)

• Configuring a special A24/A16 PCI-to-VME window (Section 2.3.3)

• Configuring VME-to-PCI address spaces (Section 2.3.4)

• Mapping UNIVERSE II CSRs to the VMEbus (Section 2.3.5)

• Mapping a location monitor window to the VMEbus (Section 2.3.6)

• Configuring VMEbus interrupts (Section 2.3.7)

• Using VMEbus software byte swapping (Section 2.3.8)

• Sharing memory between big endian and little endian processors (Section 2.3.9)

• Performing VMEbus slave block transfers (Section 2.3.10)

• Performing VMEbus master block transfers with local DMA (Section 2.3.11)

• Using the realtime interrupt-handling routine rt_post_callout (Section 2.3.12)

2.3.1    Configuring the vba_univ Subsystem

This section describes how to configure the vba_univ kernel subsystem in order to prepare UNIVERSE II-based Alpha VME systems for use on the VMEbus.

You configure the UNIVERSE II adapter by examining the default (or current) attributes supplied for the vba_univ subsystem, determining which attributes (if any) you want to change, then modifying the /etc/sysconfigtab file on your machine. After modifying /etc/sysconfigtab, you must shut down and reboot the system.

Note

Do not directly edit /etc/sysconfigtab. Instead, use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. It is recommended that you maintain private sysconfigtab file fragments for vba_univ attributes and use sysconfigdb switches to add (-a -f), delete (-d), or merge (-m -f) vba_univ attribute values. The example in Section 3.7 illustrates this approach. The sys_attrs(5) reference page provides additional guidelines for editing kernel subsystem attributes. You must always reboot after changing vba_univ subsystem attributes.

You can modify values for the following UNIVERSE II adapter attributes; each list item corresponds to a later subsection:

Adapter interrupt dispatch policy (Section 2.3.1.1)

Adapter PCI scatter/gather maximum size (Section 2.3.1.2)

Adapter DMA window maximum size (Section 2.3.1.3)

PCI coupled window timer value (Section 2.3.1.4)

PCI maximum retries (Section 2.3.1.5)

PCI posted write transfer count (Section 2.3.1.6)

PCI aligned burst size (Section 2.3.1.7)

VMEbus request level (Section 2.3.1.8)

VMEbus request mode (Section 2.3.1.9)

VMEbus release mode (Section 2.3.1.10)

VMEbus timeout period (Section 2.3.1.11)

VMEbus arbitration mode (Section 2.3.1.12)

VMEbus arbitration timeout period (Section 2.3.1.13)

System controller VMEbus resets (Section 2.3.1.14 and Section 2.3.1.15)

VMEbus on and off counters for MBLTs (Section 2.3.1.16)

You can also configure VMEbus windows in the following ways; each list item corresponds to a later subsection:

Configuring PCI-to-VME address spaces (Section 2.3.2)

Configuring a special A24/A16 PCI-to-VME window (Section 2.3.3)

Configuring VME-to-PCI address spaces (Section 2.3.4)

Mapping UNIVERSE II CSRs to the VMEbus (Section 2.3.5)

Mapping a location monitor window to the VMEbus (Section 2.3.6)

Table 2-4 lists the defaults supplied for various VMEbus parameters. The default values specified should provide proper VMEbus operation for most applications. Be careful when modifying these values; not all adapters support all fields.

Table 2-4:  UNIVERSE II VMEbus Adapter Defaults

Table 2-5 lists VMEbus interrupt parameters and their initial defaults. These defaults are later overwritten by system priority level (SPL) values supplied by the platform. See the SPL values listed in Table 2-6, or query the values at run time using the command sysconfig -q vba_univ.

Table 2-5:  UNIVERSE II VMEbus Interrupt Initial Defaults

2.3.1.1    Specifying the Adapter Interrupt Dispatch Policy

You can specify one of the following values for the adapter interrupt dispatch policy (parameter VBA_ISR_Dispatch_Policy):

2.3.1.2    Specifying the Adapter PCI Scatter/Gather Maximum Size

You can specify a multiple of 64 KB (0x10000) up to 512 MB (0x20000000) for the adapter PCI scatter/gather maximum size (parameter VBA_Max_PCI_Sg_Size). The default is 512 MB.

If the combined amount of scatter/gather resources needed to map all enabled VME-to-PCI windows exceeds the value of VBA_Max_PCI_Sg_Size, the adapter will not be configured. You can use the VBA_Max_PCI_Sg_Size parameter to constrain the consumption of PCI scatter/gather resources.

2.3.1.3    Specifying the Adapter DMA Window Maximum Size

You can specify one of the following values for the adapter DMA window maximum size (parameter VBA_Max_DMA_Wndw_Size). This value determines the amount of scatter/gather resources allocated for the DMA engine during adapter initialization. If the amount of scatter/gather resources needed for a requested DMA transfer exceeds the value of VBA_Max_DMA_Wndw_Size, the DMA transfer will be broken up into segments and the scatter/gathers will be reloaded for each segment.

You can use the VBA_Max_DMA_Wndw_Size parameter to constrain the consumption of DMA scatter/gather resources or to throttle DMA transfers (reducing granularity to force reloads).

This software resource constraint is independent of the adapter's hardware constraint on transfer size (up to 16 MB minus 2 KB of data without processor intervention).

2.3.1.4    Specifying the PCI Coupled Window Timer Value

You can specify one of the following values for the PCI coupled window timer value (parameter PCI_Coupled_Wndw_Tmr). This value is stored in the PCI Miscellaneous Register (LMISC).

The Universe II adapter uses the coupled window timer to determine how long to hold ownership of the VMEbus on behalf of the PCI Slave Channel after processing a coupled transaction. The timer is restarted each time the Universe II processes a coupled transaction. If this timer expires, then the PCI Slave Channel releases the VME Master Interface.

2.3.1.5    Specifying the PCI Maximum Retries

You can specify one of the following values for the number of PCI maximum retries before signaling errors (parameter PCI_Max_Retry). This value is stored in the Master Control Register (MAST_CTL).

2.3.1.6    Specifying the PCI Posted Write Transfer Count

You can specify one of the following values for the PCI posted write transfer count (parameter PCI_Posted_Wrt_On_Cnt). This value is stored in the Master Control Register (MAST_CTL).

2.3.1.7    Specifying the PCI Aligned Burst Size

You can specify one of the following values for the PCI aligned burst size (parameter PCI_Aligned_Burst_Size). This value is stored in the Master Control Register (MAST_CTL).

2.3.1.8    Specifying the VMEbus Request Level

You can specify one of the following values for the VMEbus request level (parameter VME_Br_Lev). This value is stored in the Master Control Register (MAST_CTL).

2.3.1.9    Specifying the VMEbus Request Mode

You can specify one of the following values for the VMEbus request mode (parameter VME_Fair_Req). This value is stored in the Master Control Register (MAST_CTL).

2.3.1.10    Specifying the VMEbus Release Mode

You can specify one of the following values for the release mode (parameter VME_Rel_Mode). This value is stored in the Master Control Register (MAST_CTL).

2.3.1.11    Specifying the VMEbus Timeout Period

You can specify one of the following values for the VMEbus timeout period (parameter VME_Bus_To). This value is stored in the Miscellaneous Control Register (MISC_CTL).

2.3.1.12    Specifying the VMEbus Arbitration Mode

You can specify one of the following values for the VMEbus arbitration mode (parameter VME_Arb_Mode). This value is stored in the Miscellaneous Control Register (MISC_CTL). This parameter is applicable only when the VMEbus adapter is configured to be the system controller.

2.3.1.13    Specifying the VMEbus Arbitration Timeout Period

You can specify one of the following values for the VMEbus arbitration timeout period (parameter VME_Arb_To). This value is stored in the Miscellaneous Control Register (MISC_CTL).

2.3.1.14    Specifying System Controller VMEbus Resets

You can specify one of the following values to indicate whether or not the adapter should issue VMEbus resets if it is the system controller (parameter VME_Syscon). This value is stored in the Miscellaneous Control Register (MISC_CTL).

For Alpha VME SBCs, in addition to specifying a value from this list, you must set the configuration switches to indicate whether or not the SBC is the VMEbus system controller. See the SBC's installation guide for information on setting the module configuration switches.

The VMEbus backplane must have only one system controller. The system controller must be electrically the first module in the VMEbus backplane and in most systems must be in the first VMEbus slot.

The values specified interact with the VMEbus initialization code to determine whether a VMEbus reset is issued when the VMEbus adapter is being configured. If the value is set to 1 and the system being booted is the system controller, as determined by the VMEbus initialization code, a VMEbus reset is issued. If you do not want a VMEbus reset issued during VMEbus adapter configuration, set the value to 0 (zero). These values pertain only to the system controller.

If the system controller is configured to issue a VMEbus reset during adapter initialization, and other processor modules are installed in the VMEbus backplane, boot the system controller first to allow devices and processor modules to perform their bus reset actions.

2.3.1.15    Special Considerations for VMEbus Resets

The system controller should always be the initiator of VMEbus resets. However, under certain error conditions, other VMEbus adapter modules may invoke a VMEbus reset. Modules installed in the VMEbus backplane react to bus resets differently. Some modules, if configured, perform a module reset. Some may have their VMEbus interface reset to a power-up state without notification to the operating system. This could leave the VMEbus adapters in an unconfigured state, cause unwanted effects to the operating system and its device drivers, and cause VMEbus errors to occur. Other VMEbus adapters on the VMEbus may accept VMEbus resets and attempt to reconfigure themselves to the hardware context they were running before the bus reset occurred. However, device drivers expecting interrupts may not receive them and I/O hardware operations may be canceled by the VMEbus reset without notification to the device driver. There is also a potential for data corruption to occur when the VMEbus adapter is reset during an I/O operation.

It is recommended that the system controller be the initiator of VMEbus resets during adapter initialization. If the system controller is not controlled by a processor, then a power-up sequence should cause all VMEbus adapters and devices to be reset. All modules on the VMEbus should perform a module reset upon detection of a bus reset. VMEbus adapters that are not the system controller and that are running an operating system should be shut down in an orderly fashion prior to the system controller being booted. These VMEbus adapters should be rebooted after the system controller has been booted, providing that the system controller is to be used and controlled by a processor.

For Alpha VME SBCs, it is recommended that nodes that are not the system controller have their module configuration switch 3 set to Closed (resets the SBC module on VMEbus reset signal). When the VMEbus is reset, and the module switch is set to accept a VMEbus reset, nonsystem controller modules take a boot action and are reset to a powered state.

If the SBC module configuration switch 3 is set to Open (does not reset the SBC module on VMEbus reset signal), the VMEbus adapter software will receive a VMEbus reset interrupt upon detection of a bus reset. The VMEbus reset signal initializes the VMEbus adapter to its power-up state. The VMEbus reset interrupt service interface displays the following message on the console terminal:

vba0 reset_inter:  VMEbus reset detected

The interrupt service interface then initializes the VMEbus adapter to its defaults and enables any previously enabled interrupt enable bits.

Do not set the SBC module configuration switch 3 to Open without considering the following side effects of receiving a VMEbus reset: device drivers expecting interrupts may not receive them and I/O hardware operations may be canceled by the VMEbus reset without notification to the device drivers. There is potential risk of data corruption depending upon I/O activity at the time a bus reset occurred.

2.3.1.16    Specifying the VMEbus On and Off Counters for MBLTs

You can specify one of the following values for the VMEbus On Counter for D64 MBLTs (parameter VME_Von_D64) or the VMEbus On Counter for D32 MBLTs (parameter VME_Von_D32). This value is stored in the DMA General Control and Status Register (DGCS).

You can specify one of the following values for the VMEbus Off Counter for D64 MBLTs (parameter VME_Voff_D64) or the VMEbus Off Counter for D32 MBLTs (parameter VME_Voff_D32). This value is stored in the DMA General Control and Status Register (DGCS).

2.3.2    Configuring PCI-to-VME Address Spaces

As part of configuring the vba_univ kernel subsystem, you can configure up to eight PCI-to-VME (PCI slave) windows, numbered 0 through 7, for your system. Additionally, you can map a special 64 MB window for VMEbus A24 and A16 accesses.

By default, the following PCI-to-VME windows are provided on your system:

Firmware allocates between 512 MB (minimum) and 960 MB (maximum) of contiguous PCI dense space for PCI-to-VME windows 0 through 7, based on what is configured in the system, and an additional, separate 64 MB for the special A24/A16 window.

The default windows 0 through 3 consume 512 MB; the default windows 4 and 5 consume 128 KB. Windows 6 and 7 can be used to map to other VMEbus address spaces, module switches, semaphores, location monitors, and so on. (However, if your configuration requires more PCI resources than are available, the adapter will not be configured.)

Between the special 64 MB A24/A16 window and the eight other windows, all of A16 and A24 space is available for access. The CPU can access a 128 MB window of A32 space with the default configuration. You have the ability to increase or decrease the size of the windows, change the VMEbus addresses and modifiers, and specify additional VMEbus windows.

Note

When configuring PCI-to-VME address spaces, you must ensure that all VMEbus devices to which the CPU will perform I/O are configured within one or more of the PCI-to-VME windows. If window sizes, VMEbus addresses, or VMEbus address modifiers are changed at a later point, you must ensure that the VMEbus devices remain within the PCI-to-VME windows.

During system initialization, if the special A24/A16 PCI-to-VME window is enabled (vba_univ parameter VME_A24_A16_Wnd_Ena equals 1), the UNIVERSE II adapter support code obtains (from firmware) the PCI address of the 64 MB window that will be used for VMEbus A24 and A16 accesses and configures the window to match your vba_univ attribute settings. For more information about configuring the A24/A16 PCI-to-VME window, see Section 2.3.3.

The UNIVERSE II adapter support code then obtains (from firmware) the PCI start and end addresses of the contiguous PCI dense space available for mapping PCI-to-VME windows 0 through 7. If enough PCI dense space is available, windows 0 through 7 are then configured to match your vba_univ attribute settings.

For hardware reasons, PCI-to-VME windows 0 and 4 must be configured on a 4 KB boundary, and their sizes must be a multiple of 4 KB. The remaining six windows must be configured on a 64 KB boundary, and their sizes must be a multiple of 64 KB. The sizes of all windows together must not exceed the limit provided in firmware.

Each PCI-to-VME window has the following configurable parameters, which you can modify in the form of vba_univ subsystem attributes:

Window enabled or disabled (Section 2.3.2.1)

VMEbus base address (Section 2.3.2.2)

Window size (Section 2.3.2.3)

VMEbus address modifiers (Section 2.3.2.4)

VMEbus maximum data width (Section 2.3.2.5)

Write posting enabled or disabled (Section 2.3.2.6)

VMEbus cycle type (Section 2.3.2.7)

When mapping to the VMEbus to fulfill a request, UNIVERSE II support code searches PCI-to-VME windows 0 through 7 in numerically ascending order, comparing the VMEbus address attributes in the request to the configured attributes of each window. The first window that satisfies the request is used. If none of the windows 0 through 7 satisfies the request, the support code checks against the special A24/A16 PCI-to-VME window.

Note that for A24 and A16 access, the support code's VMEbus mapping algorithm allows windows 0 through 7 to take precedence over the special A24/A16 window. If you want to guarantee that CSR accesses are mapped through the special A24/A16 window, you must manipulate your system's PCI-to-VME window attributes such that the CSR mappings fall through to the special window.

2.3.2.1    Enabling or Disabling a PCI-to-VME Window

To enable or disable a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_Ena attribute for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

2.3.2.2    Specifying a PCI-to-VME Window VMEbus Base Address

To establish the VMEbus base address for a PCI-to-VME window, you specify a hexadecimal address value to the VME_Wndn_VME_Address attribute for that window. The value can be in the range 0x0 to 0xFFFFFFFF, but the window base address and its associated size (VME_Wndn_Size) must fall within the addressable range of the VMEbus address space (A32, A24, or A16) selected for that window.

Windows 0 and 4 must be configured on 4 KB boundaries; the remaining six windows must be configured on 64 KB boundaries.

2.3.2.3    Specifying a PCI-to-VME Window Size

To establish the size for a PCI-to-VME window, you specify a hexadecimal size value to the VME_Wndn_Size attribute for that window. The value can be in the range 0x0 to 0xFFFFFFFF, but the window base address (VME_Wndn_VME_Address) and its associated size must fall within the addressable range of the VMEbus address space (A32, A24, or A16) selected for that window.

Windows 0 and 4 must be sized to a multiple of 4 KB; the remaining six windows must be sized to a multiple of 64 KB.

2.3.2.4    Specifying PCI-to-VME Window VMEbus Address Modifiers

To select the VMEbus address space for a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_AM_Space attribute for that window, 0 through 7, to select the VMEbus address space for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

To select user or supervisory mode for a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_AM_Usr_Sprvsr attribute for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

To select data or program access for a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_AM_Data_Prg attribute for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

2.3.2.5    Specifying a PCI-to-VME Window VMEbus Maximum Data Width

To select the VMEbus maximum data width for a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_AM_Dwdth attribute for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

2.3.2.6    Specifying PCI-to-VME Window Write Posting

To enable or disable write posting for a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_WP_Ena attribute for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

2.3.2.7    Specifying a PCI-to-VME Window VMEbus Cycle Type

To select the VMEbus cycle type for a PCI-to-VME window, you can specify one of the following values to the VME_Wndn_Cycle_Sel attribute for that window. This value is stored in the PCI Slave Image Control Register corresponding to the PCI-to-VME window number (LSIn_CTL).

2.3.3    Configuring a Special A24/A16 PCI-to-VME Window

As part of configuring the vba_univ kernel subsystem, you can configure up to eight PCI-to-VME (PCI slave) windows for your system. Additionally, you can map a special A24/A16 PCI-to-VME window, 64 MB in size, for VMEbus A24 and A16 accesses.

The 64 MB window (64 MB aligned) is subdivided into four 16 MB windows. The top 64 KB of each 16 MB quadrant is allocated for VMEbus A16 accesses. The remaining 16 MB minus 64 KB of each quadrant is allocated for VME A24 accesses.

By default, the four quadrants of the 64 MB window are set up with the following VMEbus address-modifier attributes. Note that only quadrants 0 and 2 are used for A16 access.

For example, an A16 supervisory data access would map to the top 64 KB of quadrant 2. An A24 user data access would map to the bottom 16 MB minus 64 KB of quadrant 0.

The special A24/A16 PCI-to-VME window has the following configurable parameters, which you can modify in the form of vba_univ subsystem attributes:

Window enabled or disabled (Section 2.3.3.1)

Write posting enbled or disabled (Section 2.3.3.2)

VMEbus maximum data width (Section 2.3.3.3)

During system initialization, if the special A24/A16 PCI-to-VME window is enabled (vba_univ parameter VME_A24_A16_Wnd_Ena equals 1), the UNIVERSE II adapter interface obtains (from firmware) the PCI address of the 64 MB window that will be used for VMEbus A24 and A16 accesses and configures the window to match your vba_univ attribute settings.

2.3.3.1    Enabling or Disabling the A24/A16 Window

You can specify one of the following values to the VME_A24_A16_Wnd_Ena attribute to enable or disable the special A24/A16 PCI-to-VME window. This value is stored in the Special PCI Slave Image Register (SLSI).

2.3.3.2    Specifying A24/A16 Window Write Posting

You can specify one of the following values to the VME_A24_A16_Wnd_WP_Ena attribute to enable or disable write posting to the A24/A16 window. This value is stored in the Special PCI Slave Image Register (SLSI).

2.3.3.3    Specifying the A24/A16 Window VMEbus Maximum Data Width

You can specify a 4-bit value from 0x0 to 0xF to the VME_A24_A16_Wnd_Dwdth attribute to select the A24/A16 window VMEbus maximum data width for each quadrant. This value is stored in the Special PCI Slave Image Register (SLSI).

Each bit selects D16 (0) or D32 (1) width for the corresponding quadrant, as follows:

For example, the value 0x0 (bit value 0000) selects D16 for all quadrants and the value 0xA (1010) selects D16 for quadrants 0 and 2 and D32 for quadrants 1 and 3. The default, 0xF (1111), selects D32 for all quadrants.

2.3.4    Configuring VME-to-PCI Address Spaces

As part of configuring the vba_univ kernel subsystem, you can configure up to eight VME-to-PCI (VMEbus slave) windows, numbered 0 through 7, to be used for VMEbus slave accesses in your system.

By default, the following VME-to-PCI windows are provided on your system:

Other windows can be enabled, or enabled windows can be reconfigured. All windows must be at least 64 MB in size. Windows 0 and 4 must be configured on an 8 KB boundary and must be sized to a multiple of 8 KB (minimum 64 KB), in order to line up with the PCI scatter/gather mapping register on Alpha based platforms. The remaining six windows must be configured on a 64 KB boundary and must be sized to a multiple of 64 KB. The sizes of all windows together must not exceed the total amount of resources available in the system for VME-to-PCI mapping. The number of VME-to-PCI windows enabled in the system, their sizes, and the amount of memory in the system determines the PCI resources needed. The maximum memory provided for VME-to-PCI mapping resources is determined by the VBA_Max_PCI_Sg_Size adapter attribute; the default is 512 MB.

Each VME-to-PCI window has the following configurable parameters, which you can modify in the form of vba_univ subsystem attributes:

Window enabled or disabled (Section 2.3.4.1)

VMEbus base address (Section 2.3.4.2)

Window size (Section 2.3.4.3)

VMEbus address modifiers (Section 2.3.4.4)

Write posting enabled or disabled (Section 2.3.4.5)

Prefetch reads enabled or disabled (Section 2.3.4.6)

64-bit PCI bus transactions enabled or disabled (Section 2.3.4.7)

2.3.4.1    Enabling or Disabling a VME-to-PCI Window

To enable or disable a VME-to-PCI window, you can specify one of the following values to the PCI_Wndn_Ena attribute for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

2.3.4.2    Specifying a VME-to-PCI Window VMEbus Base Address

To establish the VMEbus base address for a VME-to-PCI window, you specify a hexadecimal address value to the PCI_Wndn_VME_Address attribute for that window. The value can be in the range 0x0 to 0xFFFFFFFF, but the window base address and its associated size (PCI_Wndn_Size) must fall within the addressable range of the VMEbus address space (A32 or A24) selected for that window.

Windows 0 and 4 must be configured on 8 KB boundaries to line up with the PCI scatter/gather mapping register on Alpha based systems; the remaining six windows must be configured on 64 KB boundaries.

2.3.4.3    Specifying a VME-to-PCI Window Size

To establish the size for a VME-to-PCI window, you specify a hexadecimal size value to the PCI_Wndn_Size attribute for that window. The value can be in the range 0x0 to 0xFFFFFFFF, but the window base address (PCI_Wndn_VME_Address) and its associated size must fall within the addressable range of the VMEbus address space (A32 or A24) selected for that window.

All windows must be at least 64 KB in size. Windows 0 and 4 must be sized to a multiple of 8 KB; the remaining six windows must be sized to a multiple of 64 KB.

2.3.4.4    Specifying VME-to-PCI Window VMEbus Address Modifiers

To select the VMEbus address space for a VME-to-PCI window, you can specify one of the following values to the PCI_Wndn_AM_Space attribute for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

You can specify one of the following values to the PCI_Wndn_AM_Usr_Sprvsr attribute for a VME-to-PCI window (0 through 7) to select user mode, supervisory mode, or both for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

You can specify one of the following values to the PCI_Wndn_AM_Data_Prg attribute for a VME-to-PCI window (0 through 7) to select data access, program access, or both for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

2.3.4.5    Specifying VME-to-PCI Window Write Posting

To enable or disable write posting for a VME-to-PCI window, you can specify one of the following values to the PCI_Wndn_WP_Ena attribute for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

2.3.4.6    Specifying VME-to-PCI Window Prefetch Reads

To enable or disable prefetch reads for a VME-to-PCI window, you can specify one of the following values to the PCI_Wndn_Pre_Rd_Ena attribute for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

2.3.4.7    Specifying VME-to-PCI Window 64-Bit PCI Bus Transactions

To enable or disable 64-bit PCI bus transactions for a VME-to-PCI window, you can specify one of the following values to the PCI_Wndn_PCI64_Ena attribute for that window. This value is stored in the VMEbus Slave Image Control Register corresponding to the VME-to-PCI window number (VSIn_CTL).

Note

In order for 64-bit PCI bus transactions to be enabled, the PCI Bus Size (LCLSIZE) bit must be set in the Miscellaneous Status Register (MISC_STAT). If LCLSIZE is clear, the value of the PCI_Wndn_PCI64_Ena attribute is ignored.

2.3.5    Mapping UNIVERSE II CSRs to the VMEbus

As part of configuring the vba_univ kernel subsystem, you can map UNIVERSE II CSRs (control and status registers) to the VMEbus for your system. UNIVERSE II CSRs occupy a 4 KB window and can be enabled to support four module switches and eight semaphores.

Caution

The default vba_univ adapter configuration maps UNIVERSE II CSRs to the VMEbus for VMEbus backplane (vb) network driver use. Other drivers should not access the CSRs on the VMEbus except with extreme caution, because register changes may affect adapter code.

The default configuration of the UNIVERSE II CSRs window on the VMEbus is as follows:

You determine where in VMEbus space the UNIVERSE II CSRs are configured by modifying the following vba_univ subsystem attributes:

CSR window enabled or disabled (Section 2.3.5.1)

VMEbus base address (4 KB aligned) (Section 2.3.5.2)

VMEbus address modifiers (Section 2.3.5.3)

2.3.5.1    Enabling or Disabling the CSR Window

You can specify one of the following values to the CSR_Ena attribute to enable or disable the CSR window. This value is stored in the VMEbus Register Access Control Register (VRAI_CTL).

2.3.5.2    Specifying a CSR Window VMEbus Base Address

To establish the VMEbus base address for the CSR window, you specify a hexadecimal address value to the CSR_VME_Address attribute. The value can be in the range 0x0 to 0xFFFFFFFF, but must fall within the addressable range of the VMEbus address space (A32, A24, or A16) selected for that window. The CSR window must be configured on a 4 KB boundary.

2.3.5.3    Specifying CSR Window VMEbus Address Modifiers

You can specify one of the following values to the CSR_AM_Space attribute to select the VMEbus address space for the CSR window. This value is stored in the VMEbus Register Access Control Register (VRAI_CTL).

You can specify one of the following values to the CSR_AM_Usr_Sprvsr attribute to select user mode, supervisory mode, or both for the CSR window. This value is stored in the VMEbus Register Access Control Register (VRAI_CTL).

You can specify one of the following values to the CSR_AM_Data_Prg attribute to select data access, program access, or both for the CSR window. This value is stored in the VMEbus Register Access Control Register (VRAI_CTL).

2.3.6    Mapping a Location Monitor Window to the VMEbus

As part of configuring the vba_univ kernel subsystem, you can map a 4 KB location monitor window to the VMEbus for your system. Any read/write access to this window triggers interrupts for all UNIVERSE II-based VMEbus modules mapping the window (usable for implementing a global interrupt facility).

Note

Only UNIVERSE II-based systems can access UNIVERSE II location monitors. Accesses from VIP/VIC-based or other systems will cause bus errors.

The default configuration of the location monitor window on the VMEbus is as follows:

This window cannot reside within the VME-to-PCI windows you configure.

You determine where in VMEbus space the location monitor window is configured by modifying the following vba_univ subsystem attributes:

Location monitor window enabled or disabled (Section 2.3.6.1)

VMEbus base address (4 KB aligned) (Section 2.3.6.2)

VMEbus address modifiers (Section 2.3.6.3)

No specific operating system support exists for the location monitor registers and interrupts. To connect to location monitor interrupts, device drivers must install interrupt service interfaces for the location monitor interrupts and enable or disable location monitor interrupts.

After the location monitor interrupts are connected, any VMEbus read or write access to the UNIVERSE II location monitor window mapped to the VMEbus causes the appropriate location monitor interrupt to be generated to all interrupt-connected modules.

Device drivers must reference the location monitor window specifying matching VMEbus base address and modifiers. The device driver is responsible for knowing the location monitor window's VMEbus base address and VMEbus address modifiers.

2.3.6.1    Enabling or Disabling the Location Monitor Window

You can specify one of the following values to the LM_Ena attribute to enable or disable the location monitor window. This value is stored in the Location Monitor Control Register (LM_CTL).

2.3.6.2    Specifying a Location Monitor Window VMEbus Base Address

To establish the VMEbus base address for the location monitor window, you specify a hexadecimal address value to the LM_VME_Address attribute. The value can be in the range 0x0 to 0xFFFFFFFF, but must fall within the addressable range of the VMEbus address space (A32, A24, or A16) selected for that window. The location monitor window must be configured on a 4 KB boundary.

2.3.6.3    Specifying Location Monitor Window VMEbus Address Modifiers

You can specify one of the following values to the LM_AM_Space attribute to select the VMEbus address space for the location monitor window. This value is stored in the Location Monitor Control Register (LM_CTL).

You can specify one of the following values to the LM_AM_Usr_Sprvsr attribute to select user mode, supervisory mode, or both for the location monitor window. This value is stored in the Location Monitor Control Register (LM_CTL).

You can specify one of the following values to the LM_AM_Data_Prg attribute to select data access, program access, or both for the location monitor window. This value is stored in the Location Monitor Control Register (LM_CTL).

2.3.7    Configuring VMEbus Interrupts

This section addresses VMEbus interrupt request levels and how to specify VMEbus interrupt parameters to the software.

2.3.7.1    VMEbus Interrupt Request Levels

Table 2-6 lists the system priority levels (SPLs) at which VMEbus and VMEbus adapter interrupt requests are delivered to the operating system and device drivers. You can query your system's VMEbus SPLs at run time by issuing the command sysconfig -q vba_univ.

Table 2-6:  UNIVERSE II VMEbus Interrupt Request Levels

Alpha VME SBCs do not support autovector requests.

As Table 2-6 indicates, Alpha VME SBCs generate interrupt requests that higher-level interrupt requests can preempt.

On the Alpha VME SBCs, device drivers must use the rt_post_callout routine for interrupts delivered at SPLDEVRT. Interrupt requests for which this is needed are VMEbus IRQ7, any of the four module switch interrupts, and any of the four location monitor interrupts.

2.3.7.2    Setting VMEbus Interrupt Vector Parameters

You specify vectors and interrupt requests (IRQs) for a device driver using the Vector and Bus_Priority fields of a VBA_Option entry in the /etc/sysconfigtab file or in a sysconfigtab file fragment.

Device drivers are passed this information in the controller structure elements ivnum and bus_priority.

VMEbus interrupt vectors 24 to 255 are available to device drivers. Vectors 0 to 23 are reserved by the VMEbus adapter. When you specify a vector to the Vector field of VBA_Option, you must also use the Bus_Priority field to specify an IRQ. Valid IRQ specifications are values 1 through 7. These values correspond to VMEbus levels IRQ1 through IRQ7.

See the Autoconfiguration Support section of Writing VMEbus Device Drivers (available in the Device Driver Kit) for an example of adding and enabling VMEbus interrupts. See the vme_handler_info structure in Writing VMEbus Device Drivers for interrupt handler information.

2.3.7.3    Specifying Module Switch Interrupt Vectors

Specify one of the following vectors in the Vector field of VBA_Option to select the module switch interrupt you want. Use the Bus_Priority field to specify 7 as the IRQ level.

Module switch interrupt vectors allow a module to issue an interrupt to itself or to another module. The autoconfiguration software provides control and status registers (CSRs) for use in module switch interrupts. You can specify two CSRs in a VBA_Option entry in the /etc/sysconfigtab file or in a sysconfigtab file fragment. At boot time, the system searches for the specified CSRs.

The autoconfiguration software performs the appropriate bus mapping and provides io_handle_t values in the addr and addr2 members of the driver's controller structure. The addr argument is passed to the driver's probe routine, while the addr2 value must be obtained from the addr2 member of the controller structure.

For example, the following VBA_Option entry specifies an A32 window address as the CSR base address. The module switch 1 CSR is an offset from this A32 address.

VBA_Option = Csr1 - 0xFFFF0000, ..., Vector - 0x1150, Bus_Priority - 7, ...
 

The driver structure allows you to specify the size and address type for the CSRs. For example, the following members in a driver structure indicate that the first CSR has a size of 4096 (x1000) bytes and is in the A32 supervisory data address space:

int     addr1_size      4096
int     addr1_atype     VME_A32_SDATA

For more information, see the Device Driver Kit manuals Writing Device Drivers and Writing VMEbus Device Drivers, especially the sections on the addr and addr2 members of the controller structure and on the addr1_size, addr1_atype, addr2_size, and addr2_atype members of the driver structure.

In addition, you can use the vba_map_csr routine to provide module switch interrupts. After using the vba_map_csr routine to create an I/O handle, you write to an address derived from the base address plus an offset. The following code fragment shows how the I/O handle is created:

io_handle_t     ioh;                 /* Define type of ioh */
vme_addr_t      VME_base=0xFFFF0000; /* Base CSR address */
ioh = vba_map_csr(ctlr, VME_base, 4096,
                 (VME_A32_SDATA));

The following code fragment shows how the module switch interrupts are issued:

write_io_port(ioh+0x34C, 1, 0, data)  /* Write to CSR base address
                                      plus the offset to cause
                                      module switch 1 interrupt */
mb();

2.3.7.4    Specifying Location Monitor Interrupt Vectors

The location monitor interrupt vectors are as follows:

No specific operating system support exists for the location monitor registers and interrupts. To connect to location monitor interrupts, device drivers must install interrupt service interfaces for the location monitor interrupts and enable or disable location monitor interrupts.

When location monitor interrupts are connected, any VMEbus read or write access to the UNIVERSE II location monitor window mapped to the VMEbus causes the appropriate location monitor interrupt to be generated to all interrupt-connected modules.

For more information about configuring the UNIVERSE II location monitor window, see Section 2.3.6.

2.3.8    Using VMEbus Software Byte Swapping

Alpha processors are little endian, while VMEbus is big endian. The default operation of the UNIVERSE II adapter causes the transfer of bytes between Alpha processors and VMEbus to be arranged correctly. If, however, a 16-bit or 32-bit number is needed in a VMEbus register, the default operation rearranges the bytes within the transfer such that the bytes are reversed in significance.

For UNIVERSE II-based Alpha VME systems, software byte swapping must be used to handle these situations. (By contrast, VIP/VIC-based Alpha VME systems use hardware byte-swapping modes.)

For VMEbus device drivers, the Device Driver Kit (DDK) provides a VMEbus example device driver, DMAEX, and accompanying user code that offers a model for how you can implement software byte swapping. You can obtain VMEbus driver-writing documentation by purchasing a DDK, or you can browse a subset of DDK materials in the Library section of the Compaq Tru64 UNIX web site, currently located at:

http://www.unix.digital.com/faqs/publications/pub_page/ devdoc_list.html

Be sure to check for the latest DDK technical updates at the same location.

If your VMEbus device driver code must be portable across both VIP/VIC-based and UNIVERSE II-based Alpha VME systems, you can code the driver to use hardware or software byte swapping according to the system type.

2.3.9    Sharing Memory Between Big Endian and Little Endian Processors

In a shared memory environment, where packed data structures in common memory are shared between an Alpha processor (little endian) and a big endian processor, software byte swapping is required to arrange bytes properly for 16- or 32-bit quantities (such as 16-bit counter values or 32-bit VMEbus address values).

The following combination is recommended: UNIVERSE II default operation with software byte swapping on nonbyte data for the Alpha processor, and no swapping on the big endian processor.

You could implement software swapping with read/write macros that perform the swap with the following code. The purpose here is to provide code that would run on both little endian and big endian machines that have shared memory.

 #define read_word/long(iohandle,data)                     /
         data = read_io_port(iohandle,sizeof(word/long),0);/
 #ifdef LITTLEENDIAN                                       /
         swap_xx(data);                                    /
 #else /* BIGENDIAN */                                     /
 #endif
 #define write_word/long(iohandle,data)                    /
 #ifdef LITTLEENDIAN                                       /
         swap_xx(data);                                    /
 #else /* BIGENDIAN */                                     /
         write_io_port(iohandle,sizeof(word/long),0,data); /
 #endif

2.3.10    Performing VMEbus Slave Block Transfers

Alpha VME platforms are configured during adapter initialization to accept slave block transfers (SBLTs) with data widths of D08, D16, D32, or D64. After the SBC has mapped its memory onto the VMEbus by using the dma_map_alloc and dma_map_load routines, no other user interaction is needed. For information on calling the dma_map_alloc and dma_map_load routines, see the corresponding reference pages in the Device Driver Kit (available separately from the base operating system).

Memory must be mapped to the VMEbus prior to D64 slave access.

Access to memory must coincide with the configured access mode. By default, all access is allowed (supervisory and user, program and data). You can constrain access by modifying the default window mappings. See Section 2.3.4 for more information about configuring VME-to-PCI address spaces.

2.3.11    Performing VMEbus Master Block Transfers with Local DMA

The VMEbus interfaces for Alpha VME platforms provide a block-mode DMA engine. This DMA engine is capable of transferring up to 16 MB minus 2 KB of data without processor intervention, in VMEbus data widths of D08, D16, D32, or D64.

The DMA engine transfers data from the VMEbus to system memory (read) or from system memory to the VMEbus (write). The hardware interface handles the segmentation of the transfer. This ensures that the VMEbus specification is not violated in relation to crossing VMEbus 256-byte boundaries for D16 and D32 or 2 KB boundaries for D64.

The DMA engine is configured to give up the VMEbus during the transfer and to rearbitrate for the VMEbus again to continue the DMA. The time between when the DMA engine gives up the bus and rearbitrates for the bus is called the interleave period. During the interleave period, single-cycle VMEbus cycles, receipt of slave block transfers (SBLTs), or other operations may be performed.

The master block transfer (MBLT) hardware interface presents address modifiers of user block or supervisory block to the VMEbus, based on parameters passed in the software programming interface. The device or system on the VMEbus must be able to interpret these address modifiers; otherwise, bus errors may occur.

You can use the MBLT hardware interface to:

• Transfer data to and from those VMEbus devices that do not have their own DMA engine

• Move data between VMEbus device memory and system memory

• Transfer data to and from other systems that have their memory mapped to the VMEbus

The MBLT hardware interface supports DMA block-mode transfers to and from VMEbus A24 and A32 address space only.

2.3.11.1    Routines for Master Block-Mode Transfers

To use master block transfers (MBLTs) with the local hardware DMA engine, you must invoke the following routines and supply specific flag values:

vba_set_dma_addr

dma_map_alloc

dma_map_load

vba_dma

dma_map_unload

dma_map_dealloc

For information on calling these routines, see the corresponding reference pages in the Device Driver Kit (available separately from the base operating system).

The flag values DMA_IN and DMA_OUT have specific meaning for VMEbus support with respect to the dma_map_alloc, dma_map_load, and vba_dma routines. These flags indicate to the low-level VMEbus dma_map_alloc, dma_map_load, and vba_dma routines that the MBLT hardware DMA engine is to be used and the direction of the transfer.

Specifying DMA_IN implies a read from the VMEbus to system memory. Specifying DMA_OUT implies a write from system memory to the VMEbus. You use the vba_set_dma_addr routine to pass the flag values and the VMEbus address at which the transfer is to occur.

The VMEbus block-mode DMA engine on the VMEbus adapter is a single entity that must be shared among various device drivers. Specifying DMA_SLEEP causes the device driver to block in the vba_dma routine if the DMA engine is already being used. If DMA_SLEEP is not specified and the DMA engine is being used, vba_dma returns an error.

The following sample code shows how to invoke the MBLT hardware DMA engine for a block-mode read operation. The code uses a VMEbus transfer width of D32 to invoke a 256 KB transfer from VMEbus address A24 0x400000 to system memory. The code also allocates resources to handle transfers up to 1 MB in size. This allows dma_map_load and vba_dma to be invoked multiple times with varying size buffers. You can change the code to perform writes by substituting DMA_OUT for DMA_IN.

struct controller *ctlr;
vme_addr_t        vme_addr = 0x40000;
unsigned long     max_bc = (1024*1024);
unsigned long     rtn_bc;
char              *buffer;
unsigned long     buffer_bc = (1024 * 256);
sglist_t          dma_handle = (sglist_t)NULL;
vme_atype_t       flags = (VME_A24_UDATA_D32|DMA_IN|DMA_SLEEP);
int               rtn_flags;
/*
 *  Allocate a buffer (256 KB) to be used for the transfer
 */
MALLOC(buffer,(char *),buffer_bc,M_DEVBUF,M_WAITOK);
/*
 *  Specify a VMEbus address of 0x40000
 *  Specify flags
 *     A24 address space
 *     User mode
 *     Select DMA engine for a read (DMA_IN) and
 *       wait for DMA engine (DMA_SLEEP)
 */
rtn_flags = (int)vba_set_dma_addr(ctlr,flags,vme_addr);
/*
 *  Allocate DMA resources for up to 1 Mbyte transfer
 *    Specify flags returned from vba_set_dma_addr() above
 *    The return value from dma_map_alloc() should equal max_bc
 */
rtn_bc = dma_map_alloc(max_bc,ctlr,&dma_handle,rtn_flags);
/*
 *  Call dma_map_load() to load the resources for the
 *  DMA block-mode engine
 *    Specify the dma_handle returned from dma_map_alloc()
 *    Specify flags returned from vba_set_dma_addr()
 *    The return value from dma_map_load() should equal buffer_bc
 */
rtn_bc = dma_map_load(buffer_bc,
                      (vm_offset_t)buffer,
                      0,
                      ctlr,
                      &dma_handle,
                      0,
                      rtn_flags);
/*
 * Call vba_dma() to start up and monitor the VME adapter's block-mode
 *   DMA engine. Specify the dma_handle returned from dma_map_alloc.
 *   The return value from vba_dma() is the actual bytes transferred.
 *   This value should be the same as value buffer_bc. If not, then
 *   an error was detected during the transfer.
 */
rtn_bc = vba_dma(ctlr,dma_handle);
/*
 *  Unload and free DMA resources
 */
dma_map_unload(0,dma_handle)
dma_map_dealloc(dma_handle)

2.3.11.2    Restriction on VMEbus Master Block Transfers

The following restriction applies to using master block transfers (MBLTs) on UNIVERSE II-based Alpha VME platforms: The data buffer address and the VMEbus transfer address must be aligned exactly; that is, the 2 lowest bits must match.

For the best DMA performance, the data buffer address and the VMEbus transfer address should be word-aligned for D16, longword-aligned for D32, or quadword-aligned for D64.

2.3.12    Using the Realtime Interrupt-Handling Routine rt_post_callout

Interrupt service interfaces (ISIs) executing at SPLDEVRT (SPL 6) must not call kernel routines directly. The rt_post_callout routine allows the calling process to defer execution of a function until a time when kernel routines can be invoked. The function invoked by rt_post_callout runs at an elevated SPL and is subject to the same restrictions as an ISI.

The syntax for the function invoked by rt_post_callout is as follows:

int (*function)(),
long arg1,
long arg2 );

The parameters for the rt_post_callout routine are as follows:

If rt_post_callout is called again with the same function and arguments specified, then the duplicate invocation is dismissed before the first invocation has executed.

The following example is for an interrupt service interface (ISI) that runs at SPLDEVRT:

rt_dev_intr(unit)
        int unit;
{
 register struct rt_softc *sc = rt_softc[unit];
 rt_post_callout(user_wakeup_interface,   /* User wakeup function */
                 (long) &sc->error_recovery_flag, /* Event to wake*/
                 (long) NULL);            /* Unused argument      */
 return;
}

The following example shows a user-written function to wake up an event called by the rt_post_callout routine:

void user_wakeup_interface ( arg1, arg2 )
long arg1;
long arg2;
{
   thread_wakeup( (vm_offset_t) arg1);
}