---

D    Running Digital UNIX Software on AXPvme and Alpha VME Systems

---

D.1    VMEbus Configuration Instructions

---

D.1.1    Configuring the VMEbus Adapter

The general procedure for editing /etc/sysconfigtab is as follows:

1. Search within /etc/sysconfigtab for the label vba_vipvic:. If the label is not present, add a line with the label vba_vipvic: to the end of the file.

2. Following the label vba_vipvic:, add one or more lines specifying a parameter and its new value. For example, A32, A24, and A16 address spaces could be reconfigured as follows:

   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.

• VMEbus request level, Section D.1.2

• VIC arbitration mode, Section D.1.3

• VMEbus fairness timer value, Section D.1.4

• Local bus and VMEbus timeout periods, Section D.1.5

• VMEbus release mode, Section D.1.6

• VMEbus system controller, Section D.1.7

• VIC master write posting enable/disable, Section D.1.9

• VMEbus DMA interleave gap, Section D.1.10

• VMEbus DMA read limit enable/disable, Section D.1.11

• VMEbus DMA write limit enable/disable, Section D.1.12

• DMA method (hardware/emulated) for SMP systems, Section D.1.13

You can also modify the following values for the A32, A24, and A16 address spaces that the VMEbus hardware architecture defines:

• A32/A24 overlap/unique address configuration, Section D.1.14.1

• A32/A24 DMA inbound window sizes, Section D.1.14.2

• A32 DMA inbound window base address, Section D.1.14.3

• A24 DMA inbound window base address, Section D.1.14.4

• A16 base for interprocessor communication facilities, Section D.1.15

Table D-1 shows the defaults that Digital supplies 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.

The following VMEbus parameters pertain to VME adapters that are not embedded SBC VME designs. Embedded SBC VME designs pass this information via another mechanism.

---

D.1.2    Specifying the VMEbus Request Level

---

D.1.3    Specifying the VIC Arbitration Mode

---

D.1.4    Specifying the VMEbus Fairness Timer Value

---

D.1.5    Specifying the Local Bus and VMEbus Timeout Periods

---

D.1.6    Specifying the VMEbus Release Mode

---

D.1.7    Specifying the VMEbus Adapter as System Controller

For Digital AXPvme SBCs and Digital Alpha VME 4/nnn and 5/nnn SBCs, in addition to specifying a value from Table D-8, 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.

The values specified interact with the VMEbus initialization code to determine whether a VMEbus reset is issued when the VME 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 VME adapter configuration, set the value to 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.

---

D.1.8    Special Considerations for Receipt of VMEbus Resets

Digital 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. VME 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 VME adapters should be rebooted after the system controller has been booted, providing the system controller is to be utilized and controlled by a processor.

---

D.1.8.1    Receipt of VMEbus Resets on Digital Alpha VME 2100 Systems

---

D.1.8.2    Receipt of VMEbus Resets on Digital AXPvme and Alpha VME SBCs

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

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.

---

D.1.9    Specifying VMEbus Master Write Posting

---

D.1.10    Specifying the VMEbus DMA Interleave Gap

During the DMA interleave gap, stalled or new programmed I/O (PIO), VME 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, outstanding PIO operations, VME 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.

---

D.1.11    Specifying an 8 KB Limit on VMEbus DMA Reads

---

D.1.12    Specifying an 8 KB Limit on VMEbus DMA Writes

---

D.1.13    Specifying the DMA Method for SMP Systems

---

D.1.14    Configuring A32 and A24 Address Spaces

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. 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.

---

D.1.14.1    Specifying A32 and A24 Address Space Overlapping

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 0.

Table D-13 shows the values for overlapping and unique address spaces. 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.

---

D.1.14.2    Configuring A32 and A24 Window Sizes

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.

Table D-14 lists the window size values.

---

D.1.14.3    Specifying the A32 Base Address

---

D.1.14.4    Specifying the A24 Base Address

---

D.1.15    Configuring the A16 Address Space

---

D.1.16    VMEbus and VME Adapter Interrupt Request Levels

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 table indicates, interrupt requests from Digital AXPvme and Alpha VME Single-Board Computers (SBCs) can be preempted by higher-level interrupt requests, 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

VME device drivers written for Digital Alpha VME 2100 systems, and other platforms that deliver VME 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.

---

D.1.17    Setting VMEbus Interrupt Vector Parameters

The following sections discuss how to 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 a sysconfigtab file fragment.

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

---

D.1.17.1    Specifying VMEbus Interrupt Vectors and Interrupt Request Levels

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

---

D.1.17.2    Specifying Autovector Interrupt Vectors

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 to specify a vector value of 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.

---

D.1.17.3    Specifying Module Switch Interrupt Vectors

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 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). 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 Chapter 4 of this manual, 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();

---

D.1.17.4    Specifying Global Switch Interrupt Vectors

---

D.1.18    Using VMEbus Byte-Swap Modes

---

D.1.18.1    VME_BS_NOSWAP Mode

        Byte Address      0       1       2       3
        Little Endian   | A     | B     | C     | D     |
                        ---------------------------------
        Big Endian      | A     | B     | C     | D     |

---

D.1.18.2    VME_BS_BYTE Mode

        Byte Address      0       1       2       3
        Little Endian   | A     | B     | C     | D     |
                        ---------------------------------
        Big Endian      | B     | A     | D     | C     |

---

D.1.18.3    VME_BS_WORD Mode

        Byte Address      0       1       2       3
        Little Endian   | A     | B     | C     | D     |
                        ---------------------------------
        Big Endian      | C     | D     | A     | B     |

---

D.1.18.4    VME_BS_LWORD Mode

        Byte Address      0       1       2       3
        Little Endian   | A     | B     | C     | D     |
                        ---------------------------------
        Big Endian      | D     | C     | B     | A     |

---

D.1.18.5    Shared Memory Between Big Endian and Little Endian Processors

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 Digital 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

---

D.2    VMEbus Slave Block Transfers

---

D.3    VMEbus Master Block Transfers with Local DMA

---

D.3.1    Digital UNIX Interfaces for Master Block-Mode Transfer

• 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 VME 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)

---

D.3.2    Restrictions on VMEbus Master Block Transfers with Local DMA

• 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 VME 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.

---

D.4    Realtime Interrupt-Handling Function

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

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 wakeup  */
                  (long) NULL);                    /* unused argument      */
  return;
}

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

---

D.5    VMEbus Backplane (vb) Network Driver

---

D.5.1    DECnet Support

---

D.5.2    vb Driver Concepts

You can use all other default vb characteristics without change, as long as you configure the necessary system VMEbus window space correctly. You can also tailor several backplane node characteristics to meet specific system and application needs. The following sections describe how to configure these characteristics.

---

D.5.2.1    VMEbus Address Use by the vb Driver

• To map local memory onto the VMEbus

• To interrupt nodes on the vb network when data is sent

The following sections describe how VMEbus addresses are used for mapping data and for interrupting nodes on the vb network.

---

D.5.2.1.1    VMEbus Addresses Used for Mapping Data

The VMEbus has three different basic address spaces:

• A16

• A24

• A32

Each space is referred to as a system VMEbus window. Each system in a VMEbus backplane must configure its system VMEbus windows' base address and size in a unique manner, such that the windows do not overlap across the backplane. See Section D.1 for more information on VMEbus address spaces.

The vb driver uses either A24 or A32 space to map its client communication queues (data) to the VMEbus. The specific address within the A24 or A32 space is specified by an offset from the base of the particular window. The size of the queue data is also specified by the user.

Specify the following information regarding the queues for each backplane node:

• The address space in which to map the queues (A24 or A32) as well as other address space modifiers (supervisory/user, program/data)

• The total size of the area used to map the communication queues

• The VMEbus address where the queues will be mapped to the VMEbus, as specified by an offset from the base of the queues' chosen system VMEbus window

Default values are defined for these three items, but you can configure your vb characteristics differently by modifying values in the /usr/sys/data/if_vb_data.c file, as described in Section D.5.3. The arrows in the following code show the members to modify in if_vb_data.c:

struct vb_cfg vb_cfg = {
   /* Configurable on a per-node basis (nodes can have *
    * different values):*/
      VB_STARTUP_OFF,           /* Startup state of this driver.             */
1 --> (AM_A24|AM_SUPER|AM_DATA),/* Address modifier for VME space used       */
                                /*  for client node's message queues.        */
2 --> VB_DMA_WINDOW_SIZE,       /* Size of client VME space used for         */
                                /*  message queues.                          */
      VB_INTERRUPT,             /* Interrupt or polled driver I/O interface  */
      VB_LIVENESS_TIMEOUT_DEFAULT,/* Milliseconds interval for checking      */
                                /*  remote node liveness.                    */
      VB_A16_OFFSET_DEFAULT,    /* A16 offset for inbound module switch      */
                                /*  interrupts.                              */
      VB_MAXNODES_DEFAULT,      /* Maximum nodes in the network.             */
3 --> VB_L3OFFSET_DEFAULT,      /* Offset from base VME window address to    */
                                /*  where the client queues will be mapped   */
                                /*  onto the VME for other nodes to see.     */
                                /*  The resulting address must be on a       */
                                /*  page boundary (0x2000 bytes).            */
      {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}  /* Ethernet hardware address     */
                                            /*   of node                     */
      /* Configurable on a per-network basis (all nodes must match):         */
      VB_WELL_KNOWN_ADDRESS,    /* Well-known VME address of box manager     */
                                /*   global data. Must be on a page          */
                                /*   boundary (0x2000 bytes).                */
      VB_WELL_KNOWN_ADDRESS_TYPE, /* Address modifier of box mgr global data */
      VB_MAXMTU_DEFAULT           /* Maximum mtu size -- DO NOT MODIFY       */
};

Whatever you configure the values to be, you must modify the system VMEbus windows to accommodate the chosen values. The window (A24 or A32) base and size specified must be unique across the backplane, and its size must be big enough to fit the queue size specified, starting at the offset specified.

You can configure the system VMEbus window on a per-system basis by modifying the A24 or A32 VMEbus base address and size (parameters A32_Base, A32_Size, A24_Base, and A24_Size) in the /etc/sysconfigtab file. See Section D.1 for more information on modifying the base address and size of the system VMEbus window.

Note

If you do not uniquely configure the system VMEbus windows for the backplane nodes on the vb network, unpredictable behavior may occur. An error message similar to the following prints to the console of a node whose system VMEbus window overlaps that of a node that has mapped the window and is actively communicating through it, even if it is with a device other than the vb driver:

vba0 errors_inter: VIP/VIC errors detected
        VIC BESR 0x50 - VIP BESR 0x40400 VIC DMASR 0x8
        VMEbus timeout
        local bus error - LBERR* asserted to VIC
        Inbound error - invalid s/g or VMEbus slave access error

---

D.5.2.1.2    VMEbus Addresses Used for Interrupting

An interrupt is generated by writing to a particular offset from the base of the A16 system VMEbus window of the node to be interrupted. The offset determines the particular module switch to use for interrupting a node. A16 system windows are always 256 bytes (0x100 bytes) in size. Valid A16 base addresses are 0x0, 0x100, 0x200, and so on.

You must configure the A16 system VMEbus windows to be unique across the nodes in the VMEbus backplane. You can configure the A16 system VMEbus window on a per-system basis by modifying the A16 base address (parameter A16_Base) in the /etc/sysconfigtab file. See Section D.1 for more information on modifying the base address and size of the system VMEbus window.

There are four module switches associated with each 256-byte A16 window. You specify the module switch to use for interrupting (determined by the offset within the unique A16 window for a particular system) by modifying a value in /usr/sys/data/if_vb_data.c. If you prefer, you can use the default offset of 0x23, which is module switch 1. Table D-19 shows the valid offset values for each module switch interrupt.

Specify the following settings to use the interrupt interface in the vb driver:

• Set the interface to interrupt mode, rather than polling mode.

• Specify the module switch to use by specifying the appropriate offset within the A16 window (as specified in /etc/sysconfigtab).

Default values are defined for these two items, but you can configure your vb characteristics differently by modifying values in /usr/sys/data/if_vb_data.c, as described in Section D.5.3. The arrows in the following code show the members to modify in if_vb_data.c:

struct vb_cfg vb_cfg = {
      /* Configurable on a per-node basis (nodes can have different values): */
      VB_STARTUP_OFF,           /* Startup state of this driver.             */
      (AM_A24|AM_SUPER|AM_DATA),/* Address modifier for VME space used       */
                                /*  for client node's message queues.        */
      VB_DMA_WINDOW_SIZE,       /* Size of client VME space used for         */
                                /*  message queues.                          */
 -->  VB_INTERRUPT,             /* Interrupt or polled driver I/O interface  */
      VB_LIVENESS_TIMEOUT_DEFAULT,/* Milliseconds interval for checking      */
                                /*  remote node liveness.                    */
 -->  VB_A16_OFFSET_DEFAULT,    /* A16 offset for inbound module switch      */
                                /*  interrupts.                              */
      VB_MAXNODES_DEFAULT,      /* Maximum nodes in the network.             */
      VB_L3OFFSET_DEFAULT,      /* Offset from base VME window address to    */
                                /*  where the client queues will be mapped   */
                                /*  onto the VME for other nodes to see.     */
      {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}  /* Ethernet hardware address     */
                                            /*   of node                     */
      /* Configurable on a per-network basis (all nodes must match):         */
      VB_WELL_KNOWN_ADDRESS,      /* Well-known VME address of box manager   */
                                  /* global data.                            */
      VB_WELL_KNOWN_ADDRESS_TYPE, /* Address modifier of box mgr global data */
      VB_MAXMTU_DEFAULT           /* Maximum mtu size -- DO NOT MODIFY       */
};

Whatever you configure the values to be, the A16 system VMEbus window base address must be modified to be unique among the nodes in the VMEbus backplane for interrupting to work. However, the module switch used to interrupt a particular node can be individually configured on a per-node basis (not necessarily uniquely).

To reiterate, you can use the default offset in if_vb_data.c. However, only one of the nodes in the backplane can use the default A16 base address in /etc/sysconfigtab.

---

D.5.2.2    Box Manager Node

The box manager node is a special client in that it maps this global information onto the VMEbus in addition to mapping its client communication queues.

The box manager maps the global information onto the VMEbus at an address that is known to all other nodes in the backplane network (the well-known address). When nonbox manager nodes boot, they read information from the well-known address to see what other nodes are in the network. The well-known address must reside in the particular system VMEbus window (A24 or A32) with modifiers (supervisory/user, program/data) that are also well known to other nodes in the vb network. The combination of the address and its modifier uniquely specifies where the box manager global data resides on the VMEbus for all nodes to see.

The well-known address is configurable through if_vb_data.c, and defaults to VB_WELL_KNOWN_ADDRESS, which equals 0xA40000. The address space that it is mapped to (A24 or A32) is also configurable through if_vb_data.c and defaults to VB_WELL_KNOWN_ADDRESS_TYPE, which equals (AM_A24|AM_SUPER|AM_DATA). (See Section D.5.3.1.2 for more information on configuring the well-known address and modifiers.)

The network manager must configure only one node to be the box manager node. A node is a box manager if the well-known address is contained within the node's system VMEbus window (either A24 or A32, depending on the configured value of the box manager address modifier). There is no other switch or value to specify to identify a box manager. Note that you do not have to set the base VMEbus window address to the well-known address; the well-known address must simply be contained within a valid VMEbus system window.

When a node boots, it determines whether or not it is the box manager node by comparing the well-known address to its configured system VMEbus window range. A node that is not the box manager node is called a client node.

The box manager node is also just another network client, and it has local communication queues mapped to the VMEbus just like any other client. The difference is in the placement of those queues mapped onto the VMEbus. The box manager has two sets of data that must be mapped to the VMEbus: the box manager global data and the client communication queues.

By default, box manager global data and client communication queues are mapped to the same address space, A24. In the default case:

• The offset of the communication queues from the base window specified in if_vb_data.c for the queues is ignored.

• The communication queues are mapped directly following the global data starting at the well-known address.

In addition, the combined size of the global data and the communication queues is adjusted to be equal to the configured size of the communication queues (whose default is VB_DMA_WINDOW_SIZE). You do not need to deal with the size of the box manager global data when you determine what your system VMEbus window size should be for the box manager node.

However, you can configure the global data and the communication queues to be mapped to different spaces (A24 and A32). In this case, the communication queues are mapped like any other client node. They are mapped at the configured offset from the base of its configured window. The global data is mapped to the well-known address, for a size of 0x6000 bytes. You must be sure that both system windows, A24 and A32, will accommodate either the well-known address or the communication queues.

The box manager node must be the first node in the backplane to boot so that the global memory is mapped to the well-known address before other nodes attempt to read from it.

You must boot the VMEbus system controller for the VMEbus crate (set by the appropriate jumper on the module) before any other node that is participating in the vb backplane or any other node that is using the VMEbus. This is because when the system controller is booted, it can reset the VMEbus registers of all other nodes. If the box manager is not the VMEbus system controller, ensure that the system controller boots before the box manager node, or that the system controller is not booted while the vb network is up and running.

---

D.5.2.3    Network Participation

Once a node enters the vb network, it begins continually updating a counter in the global memory called its "heartbeat." In addition, all nodes on the network continually check the vb heartbeat of other nodes, including the box manager node, to see if they are still alive and able to participate in the network in a timely manner.

If the heartbeat of a remote node is no longer being updated, communication to that node must stop in anticipation of the remote node's VMEbus mapping becoming invalid. For example, if a node is rebooted, its heartbeat ceases to be updated and the rest of the backplane nodes eventually lose liveness with that node and stop communicating with it.

When a node is shut down in a controlled manner, (using /usr/sbin/shutdown), the vb driver notifies the other vb nodes that it is shutting down, so that they can stop communicating. If a node is shut down in an uncontrolled manner (panic or halt), the current VMEbus mappings remain valid until you reinitialize the system. This allows time for other vb network nodes to lose liveness with the node before an invalid mapping reference occurs.

Once you fully reboot the shutdown node, it can reenter the vb network, and is seen by the other vb network nodes again.

Once node A loses liveness with node B, node B cannot reenter the vb network without rebooting. You cannot restart the vb driver without rebooting. This restriction is due to the need for the restarting node to probe the well-known address to see if a box manager memory is mapped to the well-known address. This probing is supported only during the booting stage.

Response time is an important aspect of liveness. Even if a node is not shut down, it may respond too slowly to vb network traffic to be considered alive. In these cases, it may be in the best interest of the rest of the vb network to cease communication with that node. For example, a node may have a realtime application running at a realtime priority above that of the vb network driver, and in fact higher than many system functions. Without network traffic being processed in a timely manner, backups or message loss could occur on any node attempting to send data to the node.

The liveness feature of the drivers allows remote nodes to notice that the node's heartbeat is not being updated (because the node is devoted to the realtime application) and stop attempting to communicate with it. In addition, you could use a long liveness interval in a stable network configuration (one that does not expect frequent shutdowns) to allow a light load on the vb network to continue in the midst of expectedly high realtime priority usage.

---

D.5.3    Configuring the vb Network Driver

---

D.5.3.1    Editing the if_vb_data.c File

struct vb_cfg vb_cfg = {
/* Configurable on a per-node basis (nodes can have different values):      */
    VB_STARTUP_OFF,             /* Startup state of this driver.            */
    (AM_A24|AM_SUPER|AM_DATA),  /* Address modifier for VME space used      */
                                /*  for client node's message queues.       */
    VB_DMA_WINDOW_SIZE,         /* Size of client VME space used for        */
                                /*  message queues.                         */
    VB_INTERRUPT,               /* Interrupt or polled driver I/O interface */
    VB_LIVENESS_TIMEOUT_DEFAULT,/* Milliseconds interval for checking       */
                                /*  remote node liveness.                   */
    VB_A16_OFFSET_DEFAULT,      /* A16 offset for inbound module switch     */
                                /*  interrupts.                             */
    VB_MAXNODES_DEFAULT,        /* Maximum nodes in the network.            */
    VB_L3OFFSET_DEFAULT,        /* Offset from base VME window address to   */
                                /*  where the client queues will be mapped  */
                                /*  onto the VME for other nodes to see.    */
    {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}   /* Ethernet hardware address     */
                                           /*   of node                     */
/* Configurable on a per-network basis (all nodes must match):              */
    VB_WELL_KNOWN_ADDRESS,      /* well-known VME address of box manager    */
                                /*   global data.                           */
    VB_WELL_KNOWN_ADDRESS_TYPE, /* Address modifier of box mgr global data. */
    VB_MAXMTU_DEFAULT           /* Maximum mtu size -- DO NOT MODIFY        */
};

The following sections describe how a network manager can configure vb characteristics to successfully start a vb backplane network.

---

D.5.3.1.1    Per-Node Configurable Data

• Startup state

  You must change this member from VB_STARTUP_OFF to VB_STARTUP_ON to start up the vb network.

• Address modifier for client VMEbus address space

  You can map a node's queue memory to the VMEbus in either the A24 or A32 address space (AM_A24 or AM_A32), either in supervisory or user mode (AM_SUPER or not), and either in program or data space (AM_DATA or not). The default is A24 data space, supervisory mode, for example, (AM_A24|AM_SUPER|AM_DATA). A32 program space in user mode would be represented as (AM_A32).

• Size of this client's VMEbus window

  This member specifies the size (in bytes) of the VMEbus area selected from the system VMEbus window (according to the address modifier member) to be used by the vb driver for its communication queues. The bigger the size, the greater the number of message packets that will be preallocated for communication.

  The default size of VB_DMA_WINDOW_SIZE, which is 0x40000 (or 256 KB) is enough for 150 packets to be reserved for the queues. This means that if there are 10 nodes in the network, the default size will allow for 15 packets to be devoted exclusively for communication between the local node and each of the other nodes.

• Interrupt or polled driver interface

  The vb driver supports two interfaces for determining whether messages have been sent to its queues: polled or interrupt. You should use the default of VB_INTERRUPT for performance reasons, rather than the alternative VB_POLLED. The vb driver uses module switch interrupts. If you use the interrupt interface, you must ensure that the A16 system VMEbus base address for your Digital AXPvme or Alpha VME system is unique among the nodes in the backplane, as configured in the /etc/sysconfigtab file.

• Milliseconds between checking remote node liveness

  As previously described, a node continually checks to see if a remote node is still alive. It does this by default in intervals of VB_LIVENESS_TIMEOUT_DEFAULT milliseconds, which is defined as 10000 (10 seconds). Be careful when modifying this value. An interval that is too short could cause nodes to lose liveness with each other too easily, and the "lost" node (system) must be rebooted for communication to resume. An interval that is too long or an interval of 0, which specifies no liveness checking, could cause a node to take too long to determine that a remote node has gone down. In this case, the node can attempt to communicate with the shutdown node after the VMEbus mapping is invalid.

• A16 offset for inbound module switch interrupts

  You use module switches to create vb driver interrupts on the backplane. You can use four module switches for interrupts for each system VMEbus A16 base address. The specific module switch used is indicated by the particular value configured in the A16 offset member of the vb_cfg structure in if_vb_data.c. Table D-20 shows the valid offset values, and corresponding vectors, for each module switch interrupt.

  ---

  Table D-20: A16 Offset Values and Vectors for Module Switch Interrupts

  Module Switch	A16 Offset Value	Vector
  0	0x21	0x1140
  1 (default)	0x23	0x1150
  2	0x25	0x1160
  3	0x27	0x1170

  ---

  The default offset is VB_A16_OFFSET_DEFAULT, which is 0x23 (switch 1). Thus, if the A16 system VMEbus base address for node A is 0x300, remote nodes can use offset 0x23 added to 0x300 (0x323) to cause an interrupt on node A when the vb driver writes to it. The A16 system VMEbus base address must be unique among all nodes in the backplane; however, the offset itself need not be unique.

  ---

  Note

  If you change the module switch from the default of 1, this change must be reflected in the Vector field of the vb device's VBA_Option entry in the file /etc/sysconfigtab (as documented in Section D.5.5). If you do not change the vector number, interrupts will not work on the system. The default module switch 1 has a corresponding default vector of 0x1150.

  ---

• Maximum nodes in the network

  This is the maximum number of nodes that can be a part of the vb network. VB_MAXNODES_DEFAULT is defined as 10, and you cannot modify the value to greater than 32. This value is examined by the box manager only, and determines the maximum number of nodes that may enter the vb backplane network for as long as the box manager is booted. All other client nodes adjust their VB_MAXNODES value according to what the box manager's value is, and they do not have to know ahead of time what the exact value of VB_MAXNODES is on the box manager node.

• Offset from base VMEbus window address to map client queues

  VB_L3OFFSET_DEFAULT is the offset from the base system window at which the client queues will be mapped. The default is 0x0 (at the base system window). The system window (either A24 or A32) is determined by the client queue address modifier. The client queues are mapped at a fixed offset from the base window address (which you can modify in /etc/sysconfigtab). The default is to map the queues at the beginning of the base address; thus, VB_L3OFFSET_DEFAULT is defined as 0x0.

  You must have the ability to adjust the placement of the queue mappings because if other VMEbus drivers on the system use specific VMEbus addresses to map memory to, there may be conflicts. In this case, you can either adjust the base address of the particular system VMEbus window or modify the offset value such that the queues (of size specified by VB_DMA_WINDOW_SIZE, for example) start at a specific VMEbus address.

  In general, if you are not planning to use any other VMEbus devices in your systems, leave the default offset at 0x0 for all nodes. If you must change the offset, be sure the value is on a page boundary (0x2000 bytes).

• Ethernet hardware address of node

  The user must fill in this field with the Ethernet hardware address of the node. There is no default for this field. The vb network address is derived from the unique Ethernet hardware address and is the shadow Ethernet address. Thus, this field must contain the Ethernet hardware address of the node that if_vb_data.c is being modified for. If this field is not modified, the vb driver will not come up and the following error will be printed to the console:

  VB: Ethernet address contains all zeroes!  DRIVER EXITING...

  For example, if the enet address of the node is 08-00-2b-e2-48-48, you would type {0x08, 0x00, 0x2b, 0xe2, 0x48, 0x48} in the field. One way to obtain the enet address of a running system is "netstat -I ln0" (or tu0, and so on, whatever the Ethernet hardware is). You can also obtain the Ethernet address at the console prompt of a nonbooted system as follows:

  >>> show dev

---

D.5.3.1.2    Per-Network Configurable Data

• Well-known VMEbus address of the box manager

  This member is the well-known address referred to in Section D.5.2.2. It is the VMEbus address that the box manager maps global VMEbus data to. This value must be exactly the same on all nodes for the nodes to communicate at all. Take care when modifying this value.

  The default of VB_WELL_KNOWN_ADDRESS is 0xA40000. A network manager can modify this value on all nodes in the network if a specific VMEbus configuration is required.

• Address modifier of box manager data well-known address

  You can map the box manager global data to the VMEbus in either the A24 or A32 address space (AM_A24 or AM_A32), either in supervisory or user mode (AM_SUPER or not), and either in program or data space (AM_DATA or not). The default of VB_WELL_KNOWN_ADDRESS_TYPE is A24 data space, supervisory mode, for example, (AM_A24|AM_SUPER|AM_DATA). As with the well-known address values, take care to ensure that all nodes are configured exactly the same. If you do modify this value, be sure that it is on a page boundary (0x2000 bytes).

• Maximum transmit unit (mtu) size

  Do not modify this value; it is not currently configurable.

---

D.5.3.2    Editing the /etc/sysconfigtab File

Each system participating in the vb network must map its client communication queues to either A24 or A32 space in a unique manner. Thus, there must be at least enough system VMEbus window space to accommodate the size devoted to the communication queues. In addition, the system VMEbus window of the box manager node must encompass the well-known address (default of 0xA40000).

Although the address modifiers of the box manager well-known address and of the client communication queues are the same by default (A24/Super/Data), they need not be the same. If they are not the same, configure the box manager node so that its system windows accommodate both sets of data. If they are the same, configure the box manager node so that the chosen system VMEbus window accommodates both sets of data, starting at the well-known address, for a size equal to the size of the communication queues.

For interrupting, the A16 system VMEbus window base address must also be unique for all nodes in the backplane, but the size is always 0x100.

Table D-21 lists the VMEbus address space parameters you can modify in /etc/sysconfigtab, with their defaults:

See Section D.5.4 for an example of how to modify both if_vb_data.c and /etc/sysconfigtab for a valid 3-node vb network.

Note

The size of the system VMEbus window for a node should be larger than what the vb driver needs. If the vb driver uses the entire system VMEbus window, there will be no space in the VMEbus window left for other VMEbus devices on the system to use.

A system manager must carefully configure all nodes on the backplane to have large enough system VMEbus windows to accommodate the needs of each, but not so much that there is little room left for other nodes. The system manager should make a roadmap of each system's VMEbus device addresses and sizes and fit the vb needs around the needs of the other devices because the vb characteristics are user configurable.

---

D.5.4    Summary of Configuration Steps

For all three nodes, the client queues are configured to be at offset 0 (the default) from the base of the A24 system VMEbus window for the particular system. In addition, all other default values are used (for example, interrupt mode versus polling), except for the A24 base address and size and the A16 base address in /etc/sysconfigtab and the startup state in if_vb_data.c.

Configure the box manager node first. Make sure that it is either the VMEbus system controller node or that the system controller node is already up.

To configure Node 0, perform the following steps:

1. Modify /etc/sysconfigtab, changing the A24 base address (parameter A24_Base) from the default of 0xC00000 to something that encompasses the box manager data well-known address of 0xA40000. For example, set the A24 base address to 0xA00000, and change the A24 size (parameter A24_Size) to 2 MB (value 0x200000), which brings the window to just below the default window address of 0xC00000. The box manager node now has an A24 window of 0xA00000 to 0xBFFFFF.

2. Change the A16 base address (parameter A16_Base) to something other than the default of 0x100; for example, 0x000. The following is an example of the vba_vipvic: information you would add or modify in /etc/sysconfigtab.

   vba_vipvic:
           A24_Base = 0x00A00000
           A24_Size = 0x200000
           A16_Base = 0x00000000

3. Modify /usr/sys/data/if_vb_data.c, changing the startup state member from VB_STARTUP_OFF to VB_STARTUP_ON.

4. Modify /usr/sys/data/if_vb_data.c, inserting the node's Ethernet hardware address in place of {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}. For example, if the node's Ethernet address is 08-00-26-E2-48-47, you would insert {0x08, 0x00, 0x26, 0xE2, 0x48, 0x47}.

5. Run doconfig to rebuild the box manager vmunix, as described in Section D.5.5.

6. Reboot the box manager node. You should see VB: messages printed on the console, and the following message if you have correctly configured the data files:

   VB: This is the box manager node

When you configure Node 1, do not modify /etc/sysconfigtab. Instead, use the defaults, which do not overlap with the values reconfigured for the box manager node. You now have the following setup for the two nodes:

To configure Node 1, perform the following steps:

1. Modify /usr/sys/data/if_vb_data.c, changing the startup state member from VB_STARTUP_OFF to VB_STARTUP_ON.

2. Modify /usr/sys/data/if_vb_data.c, inserting the node's Ethernet hardware address in place of {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}. For example, if the node's Ethernet address is 08-00-26-E2-24-50, you would insert {0x08, 0x00, 0x26, 0xE2, 0x24, 0x50}.

3. Run doconfig to rebuild Node 1's vmunix, as described in Section D.5.5.

4. Reboot Node 1. You should see VB: messages printed on the console, and the following message if you have correctly configured the data files:

   VB: Box mgr address space is not configured for this system,
       thus this node is not the box manager node (OK).  Be sure
       that there is a box manager in the network.

To configure Node 2, perform the following steps:

1. Modify /etc/sysconfigtab.

   Node 2 cannot use the default VMEbus addresses because they are already used by Node 1. Change the A24 base address (parameter A24_Base) from the default of 0xC00000 to something unique among the other two nodes. For example, set the A24 base address to 0x400000, and keep the A24 size at the default 4 MB. Node 2 now has an A24 window of 0x400000 to 0x7FFFFF, which is the second 4-MB partition of VMEbus A24 space.

2. Change the A16 base address (parameter A16_Base) to something other than the default of 0x100, and something other than 0x000, which is Node 0's choice. For example, set it to 0x200. The following is an example of the vba_vipvic: information you would add or modify in /etc/sysconfigtab:

   vba_vipvic:
           A24_Base = 0x00400000
           A16_Base = 0x00000200

   You now have the following setup for the three nodes:

   ---

   	A24 base address	A24 end address	A16 base address
   Node 0:	0xA00000	0xBFFFFF (2 MB)	0x000
   Node 1:	0xC00000	0xFFFFFF (4 MB)	0x100
   Node 2:	0x400000	0x7FFFFF (4 MB)	0x200

   ---

3. Modify /usr/sys/data/if_vb_data.c, changing the startup state member from VB_STARTUP_OFF to VB_STARTUP_ON.

4. Modify /usr/sys/data/if_vb_data.c, inserting the node's Ethernet hardware address in place of {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}. For example, if the node's Ethernet address is 08-00-25-39-74-71, you would insert {0x08, 0x00, 0x25, 0x39, 0x74, 0x71}.

5. Run doconfig to rebuild Node 2's vmunix, as described in Section D.5.5.

6. Reboot Node 2. You should see VB: messages printed on the console, and the following message if you have correctly configured the data files:

   VB: Box mgr address space is not configured for this system,
       thus this node is not the box manager node (OK).  Be sure
       that there is a box manager in the network.

Note

Because Node 1 is using the system defaults for the VMEbus A24 window, you must make sure that if you bring up an additional node (Node 4), you modify the addresses such that the defaults are not used. Even if Node 4 does not turn on the backplane driver at all, its inbound window overlaps with Node 1. Accesses to the window will cause error messages to be printed to the screen of Node 4 because Node 4 is getting inbound VMEbus accesses from other nodes on addresses that it has not mapped inbound to.

In summary, you should always reconfigure the VMEbus addresses to be unique, no matter how you plan to use the VMEbus.

---

D.5.5    Adding the vb Driver to Digital AXPvme or Alpha VME Systems

Configure and boot the box manager node before configuring and booting any other nodes. The box manager node must be running before you configure and boot other nodes, and the VMEbus system controller module must boot before the box manager, if the box manager is not the system controller. This is because when the system controller is booted, it may reset the entire VMEbus network.

1. Save a copy of the vmunix directory:

   # cp /vmunix /vmunix.save

2. Modify the configurable data in the /usr/sys/data/if_vb_data.c file (as described in Section D.5.3). For further information, see the System Administration guide.

3. Edit the /etc/sysconfigtab file.

   If necessary, modify any VMEbus parameters at location vba_vipvic: , as described in Section D.1.1.

   If you want to change the default module switch selection of 1 to module switch 0, 2, or 3, you must change the vb driver's VBA_Option entry in the /etc/sysconfigtab file.

   Change the Vector default of 0x1150 to 0x1140, 0x1160, or 0x1170 for module switch 0, 2, or 3, respectively. The following is the VBA_Option entry you would modify in the /etc/sysconfigtab file.

   VBA_Option = Manufact_Name - 'Digital',
                Product_Name - 'VME Backplane Network Driver',
                Bus_Instance - 0, Driver_Name - vb, Driver_Instance - 0,
                Csr1 - 0, Csr2 - 0, Vector - 0x1150, Bus_Priority - 7,
                Type - C, Adpt_Config - N

   Interrupt vector 0x1150 implies module switch 1, which is the A16 address space offset 0x23. Module switch 1 is the default and is used for interrupting the driver.

4. When the doconfig utility asks if you want to edit the configuration file, answer yes and add the following line to the new configuration file:

   controller   vb0     at vba0

When you reboot the system, the VMEbus backplane driver becomes available. During the boot it displays on the console diagnostic messages prefixed with the string VB:. The box manager node displays the following message at startup:

VB: This is the box manager node

A client node (nonbox manager node) displays the following message at startup:

VB: Box mgr address space is not configured for this system,
    thus this node is not the box manager node (OK).  Be sure
    that there is a box manager in the network.

Caution

Make sure that only one node comes up as the box manager. If more than one node comes up as the box manager, it means that the system VMEbus window has been configured to contain the well-known address (whose default value is 0xA40000) on more than one node. This results in unpredictable behavior and, at a minimum, causes the vb network to fail.

---

D.5.6    Registering the vb Driver as a Network Device