 |
Index for Section 7 |
|
 |
Alphabetical listing for V |
|
vme_manual_setup(7)
NAME
vme_manual_setup, sys_attrs_vba_vipvic - 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
DESCRIPTION
VME manual setup allows you to run the Compaq Tru64 UNIX software on the
following VIP/VIC-based DIGITAL AXPvme and Alpha VME systems:
DIGITAL AXPvme single-board computers (SBCs)
DIGITAL Alpha VME 4/224 and 4/228 SBCs
DIGITAL Alpha VME 5/352 and 5/480 SBCs
DIGITAL Alpha VME 2100 system
For information about installing and configuring Tru64 UNIX on the listed
systems, refer to the Installation Guide and the Release Notes.
For information about setting up UNIVERSE-II-based Alpha VME systems for
use on the VMEbus, see the vme_univ_manual_setup(7) reference page.
This reference page addresses the following topics relating to the use of
the VMEbus on the listed systems:
· Configuring the vba_vipvic subsystem
· Configuring VMEbus A32 and A24 address spaces
· Configuring the VMEbus A16 address space
· Configuring VMEbus interrupts
· Using VMEbus hardware byte-swap modes
· Sharing memory between big/little endian processors
· VMEbus slave block transfers
· VMEbus master block transfers with local DMA
· Realtime interrupt-handling function rt_post_callout
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 attributes that
Compaq supplies 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 the
system and reboot.
Note
You should not directly edit /etc/sysconfigtab. Instead you should
use the sysconfigdb facility, as described in the sysconfigdb(8)
reference page. Compaq recommends 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 Examples section of vb(7)
illustrates this approach. Additional guidelines for editing kernel
subsystem attributes are provided in the sys_attrs(5) reference page.
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 section later in this reference page:
VMEbus request level
VIC arbitration mode
VMEbus fairness timer value
Local bus and VMEbus timeout periods
VMEbus release mode
System controller VMEbus resets enable/disable
VIC master write posting enable/disable
VMEbus DMA interleave gap
VMEbus DMA read limit enable/disable
VMEbus DMA write limit enable/disable
DMA method (hardware/emulated) for SMP systems
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 section later in this reference page:
A32/A24 overlap/unique address configuration
A32/A24 DMA inbound window sizes
A32 DMA inbound window base address
A24 DMA inbound window base address
A16 base for interprocessor communication facilities
The defaults that Compaq supplies for various VMEbus parameters are listed
below. The default values specified should provide proper VMEbus operation
for most applications. Be careful when modifying these values; not all
adapters support all fields.
Parameter Default Meaning
--------------------------------------------------------------------
VME_Br_Lev 0x03 Bus request level 3 for master cycles
VIC_Arb_Mode 0x00 Arbitration mode is round robin
VME_Fair_Req 0x00 VMEbus fair requester disabled
VIC_Loc_Bus_To 0x05 Local bus timeout period is 256
microseconds
VME_Bus_To 0x06 VMEbus timeout period is 512
microseconds
VIC_Rel_Mode 0 Release mode is release on request
(ROR)
VIC_Syscon 1 Enable system controller VMEbus resets
VIC_Wrt_Post 0 Disable VIC master write posting
VIC_DMA_Intrlv 15 DMA interleave gap is 3.75
microseconds (value * 250 nanoseconds)
Lmt_DMA_Rd 0 No DMA read limit
Lmt_DMA_Wrt 0 No DMA write limit
Frce_Hw_DMA 0 Do not force hardware DMA engine fo
SMP system
A32_Base 0x08000000 A32 inbound DMA window base address
A32_Size 0x8000000 A32 window size (128 MB)
A24_Base 0x00C00000 A24 inbound DMA window base address
A24_Size 0x400000 A24 window size (4 MB)
A16_Base 0x00000100 A16 interprocessor communication base
address
A16_Mask 0x00000000 A16 interprocessor communication mask
A24_A32_Ovrlap 1 Inbound A24/A32, if same space, overlap
The following VMEbus parameters pertain to VMEbus adapters that are not
embedded SBC VMEbus designs. Embedded SBC VMEbus designs pass this
information via another mechanism.
Parameter Default Meaning
--------------------------------------------------------------------
Irq0_SPL 3 VMEbus IRQ level to system SPL map
Irq1_SPL 3 VMEbus IRQ 1 to SPL SPLDEVLOW
Irq2_SPL 3 VMEbus IRQ 2 to SPL SPLDEVLOW
Irq3_SPL 3 VMEbus IRQ 3 to SPL SPLDEVLOW
Irq4_SPL 3 VMEbus IRQ 4 to SPL SPLDEVLOW
Irq5_SPL 3 VMEbus IRQ 5 to SPL SPLDEVLOW
Irq6_SPL 3 VMEbus IRQ 6 to SPL SPLDEVLOW
Irq7_SPL 3 VMEbus IRQ 7 to SPL SPLDEVLOW
Adapt_Blk_SPL 3 Adapter resource blocking SPL
SPLDEVLOW
DMA_Access_Space 0 Adapter MBLT I/O access: sparse
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).
0x00 VMEbus request level BR0
0x01 VMEbus request level BR1
0x02 VMEbus request level BR2
0x03 VMEbus request level BR3 (default)
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.
0x00 VIC performs round-robin VMEbus arbitration (default)
0x01 VIC performs priority VMEbus arbitration
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).
0x00 Fairness disabled (default)
0x01 Fair request timeout = 2 microseconds
0x02 Fair request timeout = 4 microseconds
0x03 Fair request timeout = 6 microseconds
0x04 Fair request timeout = 8 microseconds
0x05 Fair request timeout = 10 microseconds
0x06 Fair request timeout = 12 microseconds
0x07 Fair request timeout = 14 microseconds
0x08 Fair request timeout = 16 microseconds
0x09 Fair request timeout = 18 microseconds
0x0A Fair request timeout = 20 microseconds
0x0B Fair request timeout = 22 microseconds
0x0C Fair request timeout = 24 microseconds
0x0D Fair request timeout = 26 microseconds
0x0E Fair request timeout = 28 microseconds
0x0F Fair request timeout = none
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.
0x00 Timeout = 4 microseconds
0x01 Timeout = 16 microseconds
0x02 Timeout = 32 microseconds
0x03 Timeout = 64 microseconds
0x04 Timeout = 128 microseconds
0x05 Timeout = 256 microseconds (default for local bus)
0x06 Timeout = 512 microseconds (default for VMEbus)
0x07 Timeouts disabled
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).
0 Release on request, ROR (default)
1 Release when done, RWD
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 DIGITAL AXPvme SBCs and DIGITAL Alpha VME 4/nnn and 5/nnn SBCs, in
addition to specifying a value from this list, the configuration switches
must be set accordingly 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 DIGITAL Alpha VME 2100 adapter is always the VMEbus system controller.
There are no module configuration switches to disable it from being the
system controller.
There must be one and only one system controller in the VMEbus backplane.
The system controller must be electrically the first module in the VMEbus
backplane and in most systems must be in the first VMEbus slot.
0 Do not issue VMEbus resets if system controller
1 Issue VMEbus resets if system controller (default)
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 zero (0). 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.
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 VMEbus adapters may have their VMEbus interface reset to a
powerup state without notification to the operating system. This could
leave the VMEbus adapter 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 the VMEbus adapter to the hardware context it was
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.
Compaq recommends 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 powerup 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 the system controller is to be
utilized and controlled by a processor.
For DIGITAL 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 accessed or an
I/O operation is invoked following a bus reset, the access may result in an
adapter error, misoperation, or a system crash.
For DIGITAL AXPvme SBCs and DIGITAL Alpha VME 4/nnn and 5/nnn SBCs, Compaq
recommends 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 (VIC64) to its powerup 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.
Specifying VMEbus Master Write Posting
Master write posting is not currently supported. Do not change the value
from the default of zero (0) or unpredictable results may occur.
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.
15 Interleave gap = 3.75 microseconds (default)
14 Interleave gap = 3.50 microseconds
13 Interleave gap = 3.25 microseconds
12 Interleave gap = 3.00 microseconds
11 Interleave gap = 2.75 microseconds
10 Interleave gap = 2.50 microseconds
9 Interleave gap = 2.25 microseconds
8 Interleave gap = 2.00 microseconds
7 Interleave gap = 1.75 microseconds
6 Interleave gap = 1.50 microseconds
5 Interleave gap = 1.25 microseconds
4 Interleave gap = 1.00 microseconds
3 Interleave gap = 0.75 microseconds
2 Interleave gap = 0.50 microseconds
1 Interleave gap = 0.25 microseconds
0 Interleave gap = 0.00 microseconds
You must not specify the value zero (0) if D64 master block transfers are
to be performed. Unpredictable errors and possible data corruption may
result if you specify zero (0) 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 zero (0), 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.
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.
0 No DMA read limit (default)
1 Limit DMA reads to 8 KB or less
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.
0 No DMA write limit (default)
1 Limit DMA writes to 8 KB or less
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.
0 Use emulated DMA on SMP system (default)
1 Force hardware MBLT on SMP system
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 out 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.
Specifying A32/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,
the autoconfiguration software must be configured to disallow A32 direct
memory access allocations within the first 16 MB of VMEbus address space.
If this is not done, 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 zero (0).
The values for overlapping and unique address spaces are listed below.
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).
0 A24 and A32 addresses must be unique
1 A24 and A32 addresses can overlap each other (default)
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:
0x10000 64 KB
0x20000 128 KB
0x40000 256 KB
0x80000 512 KB
0x100000 1024 KB (1 MB)
0x200000 2048 KB (2 MB)
0x400000 4096 KB (4 MB) [A24 default]
0x800000 8192 KB (8 MB)
0x1000000 16384 KB (16 MB)
0x2000000 32768 KB (32 MB)
0x4000000 65536 KB (64 MB)
0x8000000 131072 KB (128 MB) [A32 default]
Specifying the A32 Base Address
You specify the A32 base address using the A32_Base parameter. The values
used for partitioning 128 MB windows in the A32 address space are listed
below. 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.
Base Size Bus Address Bus Offset
(Bits 31-24) (A32_Base)
--------------------------------------------------
0000 0000 128 MB 0x00000000 0 MB
--------------------------------------------------
0000 0000 64 MB 0x00000000 0 MB
0000 0100 64 MB 0x04000000 64 MB
--------------------------------------------------
0000 0000 32 MB 0x00000000 0 MB
0000 0010 32 MB 0x02000000 32 MB
0000 0100 32 MB 0x04000000 64 MB
0000 0110 32 MB 0x06000000 96 MB
--------------------------------------------------
0000 0000 16 MB 0x00000000 0 MB
0000 0001 16 MB 0x01000000 16 MB
0000 0010 16 MB 0x02000000 32 MB
0000 0011 16 MB 0x03000000 48 MB
0000 0100 16 MB 0x04000000 64 MB
0000 0101 16 MB 0x05000000 80 MB
0000 0110 16 MB 0x06000000 96 MB
0000 0111 16 MB 0x07000000 112 MB
--------------------------------------------------
Specifying the A24 Base Address
You specify the A24 base address using the A24_Base parameter. The base
address values for windows in the A24 address space are listed below. The
base address is stored in bits 16 through 23. The table has been truncated
for the smaller window sizes.
Base Size Bus Address Bus Offset
(Bits 23-16) (A24_Base)
--------------------------------------------------
0000 0000 16 MB 0x00000000 0 MB
--------------------------------------------------
0000 0000 8 MB 0x00000000 0 MB
1000 0000 8 MB 0x00800000 16 MB
--------------------------------------------------
0000 0000 4 MB 0x00000000 0 MB
0100 0000 4 MB 0x00400000 4 MB
1000 0000 4 MB 0x00800000 8 MB
1100 0000 4 MB 0x00C00000 12 MB
--------------------------------------------------
0000 0000 2 MB 0x00000000 0 MB
0010 0000 2 MB 0x00200000 2 MB
0100 0000 2 MB 0x00400000 4 MB
0110 0000 2 MB 0x00600000 6 MB
1000 0000 2 MB 0x00800000 8 MB
1010 0000 2 MB 0x00A00000 10 MB
1100 0000 2 MB 0x00C00000 12 MB
1110 0000 2 MB 0x00E00000 14 MB
--------------------------------------------------
0000 0000 1 MB 0x00000000 0 MB
0001 0000 1 MB 0x00100000 1 MB
0010 0000 1 MB 0x00200000 2 MB
0011 0000 1 MB 0x00300000 3 MB
0100 0000 1 MB 0x00400000 4 MB
0101 0000 1 MB 0x00500000 5 MB
0110 0000 1 MB 0x00600000 6 MB
0111 0000 1 MB 0x00700000 7 MB
1000 0000 1 MB 0x00800000 8 MB
1001 0000 1 MB 0x00900000 9 MB
1010 0000 1 MB 0x00A00000 10 MB
1011 0000 1 MB 0x00B00000 11 MB
1100 0000 1 MB 0x00C00000 12 MB
1101 0000 1 MB 0x00D00000 13 MB
1110 0000 1 MB 0x00E00000 14 MB
1111 0000 1 MB 0x00F00000 15 MB
--------------------------------------------------
0000 0000 512 KB 0x00000000 0 KB
0000 1000 512 KB 0x00080000 512 KB
0001 0000 512 KB 0x00100000 1024 KB
0001 1000 512 KB 0x00180000 1536 KB
0010 0000 512 KB 0x00200000 2048 KB
... ... ... ...
1111 1000 512 KB 0x00F80000 15872 KB
--------------------------------------------------
0000 0000 256 KB 0x00000000 0 KB
0000 0100 256 KB 0x00040000 256 KB
0000 1000 256 KB 0x00080000 512 KB
0000 1100 256 KB 0x000C0000 786 KB
0001 0000 256 KB 0x00100000 1024 KB
... ... ... ...
1111 1100 256 KB 0x00FC0000 16128 KB
--------------------------------------------------
0000 0000 128 KB 0x00000000 0 KB
0000 0010 128 KB 0x00020000 128 KB
0000 0100 128 KB 0x00040000 256 KB
0000 0110 128 KB 0x00060000 384 KB
0000 1000 128 KB 0x00080000 512 KB
... ... ... ...
1111 1110 128 KB 0x00FE0000 16256 KB
--------------------------------------------------
0000 0000 64 KB 0x00000000 0 KB
0000 0001 64 KB 0x00010000 64 KB
0000 0010 64 KB 0x00020000 128 KB
0000 0011 64 KB 0x00030000 192 KB
0000 0100 64 KB 0x00040000 256 KB
... ... ... ...
1111 1111 64 KB 0x00FF0000 16320 KB
--------------------------------------------------
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
hex to FFFF hex. You can configure the VMEbus Interprocessor Communication
Facilities (ICF) of the DIGITAL AXPvme SBC, DIGITAL Alpha VME 4/nnn or
5/nnn SBC, or DIGITAL 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).
Configuring VMEbus Interrupts
This section addresses VMEbus interrupt request levels and how to configure
VMEbus interrupts in the software.
VMEbus Interrupt Request Levels
The system SPL levels at which VMEbus and VMEbus adapter interrupt requests
are delivered to the operating system and device drivers are listed below:
Interrupt AXPvme SBC Alpha VME n/nnn Alpha VME 2100
Request Name SPL Levels SBC SPL Levels SPL Levels
---------------------------------------------------------------
VMEbus IRQ 1 SPLDEVLOW SPLDEVLOW SPLDEVLOW
VMEbus IRQ 2 SPLDEVLOW SPLDEVLOW SPLDEVLOW
VMEbus IRQ 3 SPLDEVLOW SPLDEVLOW SPLDEVLOW
VMEbus IRQ 4 SPLDEVHIGH SPLDEVHIGH SPLDEVLOW
VMEbus IRQ 5 SPLDEVHIGH SPLDEVHIGH SPLDEVLOW
VMEbus IRQ 6 SPLDEVHIGH SPLDEVHIGH SPLDEVLOW
VMEbus IRQ 7 SPLDEVRT SPLDEVRT SPLDEVLOW
Autovector IRQ 1 SPLDEVLOW
Autovector IRQ 2 SPLDEVLOW
Autovector IRQ 3 SPLDEVLOW
Autovector IRQ 4 SPLDEVHIGH
Autovector IRQ 5 SPLDEVHIGH
Autovector IRQ 6 SPLDEVHIGH
Autovector IRQ 7 SPLDEVRT
VMEbus Reset SPLDEVRT SPLDEVRT
Module Switches SPLDEVRT SPLDEVRT SPLDEVLOW
VMEbus IACK SPLDEVLOW SPLDEVLOW SPLDEVLOW
DMA Status SPLDEVRT SPLDEVRT SPLDEVLOW
The DIGITAL Alpha VME 4/nnn and 5/nnn SBCs do not support autovector
requests. The DIGITAL Alpha VME 2100 system does not support autovector
and VMEbus reset interrupt requests.
As the previous list indicates, DIGITAL AXPvme and Alpha VME SBCs generate
interrupt requests that higher-level interrupt requests can preempt, while
DIGITAL Alpha VME 2100 interrupt requests are all delivered at the same SPL
level and cannot be preempted.
On the DIGITAL AXPvme and Alpha VME SBCs, device drivers must use the
rt_post_callout function 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 function will also run on the DIGITAL Alpha
VME 2100 system without modifications.
Note
VMEbus device drivers written for DIGITAL Alpha VME 2100 systems, and
other platforms that deliver VMEbus interrupts at the same SPL level,
may be affected when running these device drivers on the DIGITAL
AXPvme or Alpha VME SBC platforms. If these device drivers are using
SPL levels to protect common resources between thread and interrupt
service interfaces, the preempted interrupts of the SBC systems may
have unwanted effects on these device drivers. If these device drivers
are servicing interrupts for VMEbus IRQ7, Autovector IRQ7, or module
switch interrupts, then these device drivers must be modified to use
the rt_post_callout function. Device drivers cannot invoke normal
thread wakeup mechanisms at SPLDEVRT.
Setting VMEbus Interrupt Vector Parameters
Refer to the Autoconfiguration Support section of Writing VMEbus Device
Drivers for an example of adding and enabling VMEbus interrupts. Refer to
the vme_handler_info structure in Writing VMEbus Device Drivers for
interrupt handler information.
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.
Specifying Autovector Interrupt Vectors
The DIGITAL 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 do not have the capability of presenting a
status/ID vector as do the 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. It is the
responsibility of the device driver to dismiss the RORA device's interrupt
request by performing a read or write access to the device. Refer to 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 zero (0) 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.
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 0
Vector 0x1140
Module switch 1
Vector 0x1150 (default)
Module switch 2
Vector 0x1160
Module switch 3
Vector 0x1170
Module switch interrupt vectors allow a module to issue an interrupt to
itself or to another module. The autoconfiguration software provides
control 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
interface, 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 0 CSR is an offset from this A16 address.
VBA_Option = Csr1 - 0x100, ..., Vector - 0x1140, 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 Writing Device Drivers: Tutorial 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 function to provide module switch
interrupts. After using the vba_map_csr function 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+0x20, 1, 0, 0) /* write to A16 base address
plus the offset to clear
module switch 0 */
mb();
write_io_port(ioh+0x21, 1, 0, 0) /* write to A16 base address
plus the offset to set
module switch 0 */
mb();
Specifying Global Switch Interrupt Vectors
Global switch interrupts are not currently supported.
Using VMEbus Hardware Byte-Swap Modes
Alpha processors are little endian, while VMEbus is big endian. The
default byte-swap mode, VME_BS_NOSWAP, 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 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, dma_map_alloc or dma_map_load, and the driver structure.
VME_BS_NOSWAP mode provides a hardware mechanism for data coherency for
byte-data transfers from Alpha processors (little endian) to VMEbus (big
endian). The address of any byte as seen on the two busses 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:
Byte Address 0 1 2 3
Little Endian | A | B | C | D |
---------------------------------
Big Endian | A | B | C | D |
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, only 16-bit aligned transfers should be used. Byte-swap mode
byte addressing is as follows:
Byte Address 0 1 2 3
Little Endian | A | B | C | D |
---------------------------------
Big Endian | B | A | D | C |
VMS_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 data-size
dependent. For DIGITAL AXPvme and Alpha VME platforms, system word swap-
mode byte addressing is as follows:
Byte Address 0 1 2 3
Little Endian | A | B | C | D |
---------------------------------
Big Endian | C | D | A | B |
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, only 32-bit transfers should be used. Longword swap-mode byte
addressing is as follows:
Byte Address 0 1 2 3
Little Endian | A | B | C | D |
---------------------------------
Big Endian | D | C | B | A |
Sharing Memory Between Big/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).
Compaq recommends the following combination: VME_BS_NOSWAP with software
byte swapping on nonbyte data for the Alpha processor; and no swapping on
the big endian processor.
Software swapping could be implemented 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
VMEbus Slave Block Transfers
The DIGITAL AXPvme and Alpha VME platforms are configured to accept slave
block transfers (SBLTs) with data widths of D16, D32, or D64 during adapter
initialization. Once the SBC has mapped its memory onto the VMEbus by using
the dma_map_alloc and dma_map_load functions, no other user interaction is
needed.
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.
VMEbus Master Block Transfers with Local DMA
The VMEbus interfaces for the DIGITAL 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 Tru64 UNIX 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.
Interfaces for Master Block-Mode Transfers
To use the master block transfer (MBLT) with the local hardware DMA engine,
you must invoke the following interfaces with specific flag values
specified:
vba_set_dma_addr
dma_map_alloc
dma_map_load
vba_dma
dma_map_unload
dma_map_dealloc
The vba_dma interface is used to start up and monitor the DMA engine. See
the vba_dma() reference page for information on the vba_dma calling
interface.
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 interfaces.
These flags indicate to the low-level VMEbus dma_map_alloc, dma_map_load,
and vba_dma interfaces 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 interface 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 interface if the DMA
engine is already being utilized. If DMA_SLEEP is not specified and the DMA
engine is being utilized, vba_dma returns an error indication.
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)
Restrictions on VMEbus Master Block Transfers
Several restrictions apply to using master block transfers (MBLTs) on the
DIGITAL AXPvme and Alpha VME platforms. These restrictions are listed by
data-width selection of D16, D32, and D64.
· D08 (unsupported)
· D16 restrictions
The VMEbus address must be longword aligned (0, 4, 8, and so forth).
The memory address must be word aligned (0, 2, 4, and so forth). The
requested byte count must be a multiple of 2.
· D32 restrictions
The VMEbus address must be longword aligned (0, 4, 8, and so forth).
The memory address must be longword aligned (0, 4, 8, and so forth).
The requested byte count must be a multiple of 4.
· D64 restrictions
The VMEbus address must be quadword aligned (0, 8, 16, and so forth).
The memory address must be quadword aligned (0, 8, 16, and so forth).
The requested byte count must be a multiple of 8.
The DIGITAL Alpha VME 2100 system in an SMP environment emulates DMA
transfers via PIO operations in lieu of using the 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.
Realtime Interrupt-Handling Function rt_post_callout
Interrupt service interfaces (ISIs) executing at SPLDEVRT (SPL 6) must not
call kernel interfaces directly. The rt_post_callout function allows the
calling process to defer execution of a function until a time when kernel
interfaces 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 rt_post_callout function is as follows:
int (*function)(),
long arg1,
long arg2 );
The parameters for the rt_post_callout function are as follows:
function Name of the function to be invoked
arg1 The first argument passed to the function
arg2 The second argument passed to the function
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 function:
void user_wakeup_interface ( arg1, arg2 )
long arg1;
long arg2;
{
thread_wakeup( (vm_offset_t) arg1);
}
RELATED INFORMATION
Interfaces: vb(7), vme_univ_manual_setup(7), sysconfigdb(8), sys_attrs(5)
Writing VMEbus Device Drivers in the DIGITAL UNIX Device Driver Kit