3 Data Link Layer Components

3.1 Introduction

The data link layer consists of the drivers that directly transmit and receive frames on the physical network medium. The VxWorks stack bundles Ethernet drivers and the shared-memory backplane network driver, which provides communication over a backplane.

NOTE: The bundled PPP, SLIP and CSLIP implementations previously described in this chapter are now deprecated for future use and will be removed from the next major release of Tornado. In anticipation of this change, the configuration information for the bundled PPP, SLIP and CSLIP implementations has been moved to C. Bundled PPP, SLIP, and CSLIP. For more information on the discontinuance of these features, please contact your local Wind River account manager.

If you require a PPP solution, please ask your Wind River account manager about WindNet PPP. WindNet PPP is a reliable and manageable PPP solution built upon an extensible Remote Access Framework.

3.2 Ethernet Driver Support

Ethernet is one medium among many over which the VxWorks network stack can operate. Ethernet is a local area network specification that is supported by numerous vendors. If you are writing or porting an Ethernet driver to the VxWorks network stack, it should conform to the MUX interface for network drivers. This interface includes support for features such as multicasting and polled-mode Ethernet. For information on how to write a driver that works with the MUX, see 10. Integrating a New Network Interface Driver.

3.2.1 BPF, the BSD Packet Filter

This network stack implementation supports the BSD Packet Filter (BPF) as a method of inspecting incoming data. One advantage of using BPF rather than an input hook (a technique now deprecated) is that you can use BPF from outside of the kernel protection domain. This is possible because packets caught by the filter can be copied to an area of data that is available outside of the kernel protection domain.

NOTE: The input hook depends on the etherInputHookAdd( ) functionality supplied by etherLib, a library now deprecated for future use. Although this library is still supported, it will be removed from the next major release or Tornado.

To create a BPF device, take the following steps:

Call bpfDrv( ) to initialize the BPF driver - you should check to make sure this routine does not return ERROR.

Call bpfDevCreate( ) to create a BPF device.

STATUS bpfDevCreate 
    ( 
    char *  pDevName,       /* I/O system device name */ 
    int     numUnits,       /* number of device units */ 
    int     bufSize         /* block size for the BPF device */ 
    )

The device name should be something like /dev/bpf or /bpf/foo. The number of units should be set to the maximum number of BPF units for the device - for example, if you want to use /dev/bpf0 and /dev/bpf1, numUnits should be set to at least 2. The buffer size should be less than or equal to the MTU, and the buffer you use to read data from the BPF device should be at least as large as this bufSize.

Call open( ) to get a file descriptor for one of these BPF units, for example:

bpffd = open( "/dev/bpf0", 0, 0 )

Set any desired options for this unit by using ioctl commands - for instance:

int arg = 1; 
int status = ioctl (bpffd, BIOCIMMEDIATE, (int)&arg);

Use the BIOCSETF ioctl command to set a filter for the BPF device. This filter is written according to the bpf_program template. Incoming packets that match this filter will be passed to the associated BPF device.

Use the BIOCSETIF ioctl command to attach the file descriptor associated with your BPF device unit to a specific network interface.

3.2.2 Additional Filter Syntax

The BPF_TYPE alias finds the type of link level frame. Use it in statements such as:

BPF_STMT(BPF_LD+BPF_TYPE,0)  /* Save lltype in accumulator */

The BPF_HLEN alias determines the header length, independently of the variety of link layer header in use. Use it in statements such as:

BPF_STMT(BPF_LD+BPF_H+BPF_ABS+BPF_HLEN, 6) /* IP fragment field */

3.3 The Shared-Memory Backplane Network Driver

The smEnd (Tornado 3) or if_sm (Tornado 2) shared-memory backplane network driver allows multiple processors to communicate over their common backplane as if they were communicating over a network by using a standard 4.4 BSD compatible (if_sm) or MUX-capable (smEnd) network driver.¹

A multiprocessor backplane bus is an Internet network with its own network / subnet number. The hosts on this network (the processors) have their own unique IP addresses. In the example shown in Figure 3-1, two CPUs are on a backplane. The Internet address for the shared-memory backplane network is 161.27.0.0. Each CPU on the shared-memory backplane network has a unique Internet address, 161.27.0.1 for vx1 and 161.27.0.2 for vx2.

Figure 3-1 : Shared-Memory Backplane Network

Processors can communicate with other hosts on the Internet, or with each other, by using the smEnd or if_sm driver. The driver behaves as any other network driver, and thus a variety of network services can communicate through it.

3.3.1 The Backplane Shared-Memory Region

The contiguous memory region accessible to all processors on the backplane is the physical medium that lets the smEnd or if_sm driver simulate driver-style communication.²

Backplane Processor Numbers

Each processor on the backplane is assigned a unique backplane processor number starting with 0. The assignment of numbers is arbitrary, except for processor 0, which by convention and by default is the shared-memory backplane network master, described in The Shared-Memory Network Master, p.23.

You set the processor numbers in the boot-line parameters passed to the boot image. You can burn these parameters into ROM, set them in the processor's NVRAM (if available), or enter them manually.

NOTE: Using the smEnd available with Tornado 3, you can set up two shared memory networks on a single backplane with a single processor being a node on each network. However, if you are using the optional VxMP product, you can use only one shared memory network over the backplane. In this case, the processor number of the master node is assigned to and fixed at zero.

The Shared-Memory Network Master

One processor on the backplane is the shared-memory network master. The shared-memory network master has the following responsibilities:

Initialize the shared-memory region and the shared-memory anchor

Maintain the shared-memory backplane network heartbeat

Function (usually) as the gateway to the external network

Allocate the shared-memory region (if requested)

No processor can use the shared-memory backplane network until the shared-memory network master has initialized it. However, the master processor is not involved in the actual transmission of packets on the backplane between other processors. After the shared-memory region is initialized, all of the processors, including the master, are peers.

Under Tornado 3, a configuration parameter determines the processor number of the master. Knowing this, a Tornado 3 node can determine at run time whether it is the master node by comparing the configured processor number with that assigned to it in the boot parameters. Under Tornado 2, the processor number of the master is always zero. A Tornado 2 node can determine at run time whether it is the master by examining the processor number assigned to it in the boot parameters.

Typically, the master has two Internet addresses in the system: its Internet address on the external network, and its address on the shared-memory backplane network. (See the reference entry for usrConfig.)

The other processors on the backplane can boot indirectly over the shared-memory backplane network, using the master as the gateway. They need only have an Internet address on the shared-memory backplane network. These processors specify the shared-memory backplane network interface, esm, (Tornado 3) or sm (Tornado 3), as the boot device in the boot parameters.

The Shared-Memory Anchor

The location of the shared-memory region depends on the system configuration. All processors on the shared-memory backplane network must be able to access the shared-memory region within the same bus address space as the anchor.

The shared-memory anchor serves as a common point of reference for all processors. The anchor structure and the shared memory region may be located in the dual-ported memory of one of the participating boards (the master by default) or in the memory of a separate memory board.

NOTE: Some BSPs support locating the anchor and shared memory regions on a participating non-master board. For examples of how to do this, see the Compact PCI bus BSPs mcp750 and mcpn750.

The anchor contains an offset to the actual shared-memory region. The master sets this value during initialization. The offset is relative to the anchor itself. Thus, the anchor and region must be in the same bus address space so that the offset is linear and valid for all processors.

The anchor address is established by configuration parameters or by boot parameters. For the shared-memory network master, the local anchor address is assigned in the master's configuration at the time the system image is built.

Under Tornado 3, you set the shared memory anchor backplane bus address, as seen by all boards, at build time. Two values determine the anchor location. These values are a backplane bus address space specification (configuration parameter: SM_ADRS_SPACE) and a bus address within that space (configuration parameter: SM_ANCHOR_ADRS). Local, PCI and VME buses are supported.

Under Tornado 2, the shared memory anchor bus address is always a local bus address. You can set this address using the SM_ANCHOR_OFFSET and SM_ANCHOR_ADRS configuration parameters accessible from the INCLUDE_SM_COMMON configuration component. You can also set this address at run time as an aspect of the mapping between a slave's local bus address space and the backplane bus address space. (For more information, see the reference entries for sysBusToLocalAdrs( ) and sysLocalToBusAdrs( ).)

For the slave processors on the shared-memory backplane network, a default anchor bus address can also be assigned during configuration in the same way. However, this requires burning boot ROMs with that configuration, because the other processors must, at first, boot from the shared-memory backplane network. For this reason, the anchor address can also be specified in the boot parameters if the shared-memory backplane network interface is the boot device.

Under Tornado 3, the boot line format is bootDevName=busAdrsSpace:busAdrs. For example:

esm=0x0d:0x10010000

In this case, this is the backplane bus address of the anchor as seen by all processors. Note that the busAdrsSpace section should not specify the local bus if the board is a slave.

Under Tornado 2, the boot line format is bootDevName=localAdrs. For example:

sm=0x10010000

This is the local address of the anchor as seen by the processor being booted.

The Shared-Memory Backplane Network Heartbeat

The processors on the shared-memory backplane network cannot communicate over that network until the shared-memory region initialization is finished. To let the other processors know when the backplane is "alive," the master maintains a backplane network heartbeat. This heartbeat is a counter that is incremented by the master once per second. Processors on the shared-memory backplane network determine that the shared-memory backplane network is alive by watching the heartbeat for a few seconds.

The shared-memory backplane heartbeat is located in the first 4-byte word of the shared-memory packet header. The offset of the shared-memory packet header is the fifth 4-byte word in the anchor, as shown in Figure 3-2.

Figure 3-2 : Shared-Memory Backplane Network Heartbeat

Shared-Memory Location

Assigning the shared-memory location differs according to whether you are working under Tornado 2 or Tornado 3.

Tornado 3

Shared memory is assigned a fixed location at compile time. The location is determined by the value of the shared memory address set through a logical region entry in the 00region.sdf file for that board's BSP. Because all processors on the backplane access the shared-memory region, you must configure that memory as non-cacheable. This can be configured in the 00region.sdf file.

Tornado 2

Shared memory is, by default, assigned a fixed location and size at compile time. The location is determined by the value of the shared memory address set through the SM_MEM_ADRS parameter in the INCLDUE_SM_COMMON component for that board. Because all processors on the backplane access the shared-memory region, you must configure that memory as non-cacheable.

The shared memory backplane network region (not including the anchor) can also be allocated at run time if you set SM_MEM_ADRS to NONE. In this case, a region of size SM_MEM_SIZE is allocated and made non-cacheable.

Shared Memory Size

The size of the shared-memory backplane network area is set in the build-time configuration information. The relevant configuration parameter is SM_NET_MEM_SIZE (Tornado 3) or SM_MEM_SIZE (Tornado 2).

A related area, the shared-memory object area, used by the optional VxMP product, is governed by the configuration parameter SM_OBJ_MEM_SIZE. If either the network or VxMP is not installed or used, set the corresponding size parameter to zero. You must do this because the total size of shared memory allocated or assigned is the sum of the network and VxMP sizes.

The size required for the shared-memory backplane network area depends on the number of processors and the expected traffic. There is less than 2KB of overhead for data structures. After that, the shared-memory backplane network area is divided into 2KB packets. Thus, the maximum number of packets available on the backplane network is (areasize - 2KB) / 2KB. A reasonable minimum is 64KB. A configuration with a large number of processors on one backplane and many simultaneous connections can require as much as 512KB. If you reserve a backplane network memory area that is too small, you will slow network communication.

Test-and-Set to Shared Memory

To prevent more than one processor from simultaneously accessing certain critical data structures of the shared-memory region, the shared memory backplane network driver uses an indivisible test-and-set (TAS) instruction to obtain exclusive use of a shared-memory data structure. This translates into a read-modify-write (RMW) cycle on the backplane bus.³

It is important that the selected shared memory supports the RMW cycle on the bus and guarantees the indivisibility of such cycles. This is especially problematic if the memory is dual-ported, as the memory must then lock out one port during a RMW cycle on the other.

Some processors do not support RMW indivisibly in hardware, but do have software hooks to provide the capability. For example, some processor boards have a flag that can be set to prevent the board from releasing the backplane bus, after it is acquired, until that flag is cleared. You can implement these techniques for a processor in the sysBusTas( ) routine of the system-dependent library sysLib. The shared memory backplane network driver calls this routine to set up mutual exclusion on shared-memory data structures.

CAUTION: Configure the shared memory test-and-set type (configuration parameter: SM_TAS_TYPE) to either SM_TAS_SOFT or SM_TAS_HARD. If even one processor on the backplane lacks hardware test and set, all processors in the backplane must use the software test and set (SM_TAS_SOFT).

NOTE: The shared memory backplane network driver does not support the specification of TAS operation size. This size is architecture dependent.

3.3.2 Interprocessor Interrupts

Each processor on the backplane has a single input queue for packets received from other processors. To attend to its input queue, a processor can either poll or rely on interrupts (either bus interrupts or mailbox interrupts). When using polling, the processor examines its input queue at fixed intervals. When using interrupts, the sending processor notifies the receiving processor that its input queue contains packets.

Interrupt-driven communication using either bus interrupts or mailbox interrupts is more efficient than polling in that it invests as few cycles in communication as is possible (although at a cost of greater latency). Unfortunately, the bus interrupt mechanism can handle only as many processors as there are interrupt lines available on the backplane (for example, VMEbus has seven). In addition, not all processor boards are capable of generating bus interrupts.

As an alternative to bus interrupts, you can use mailbox interrupts, also called location monitors because they monitor the access to specific memory locations. A mailbox interrupt specifies a bus address that, when written to or read from, causes a specific interrupt on the processor board. Using hardware jumpers or software registers, you can set each board to use a different address for its mailbox interrupt.

To generate a mailbox interrupt, a processor accesses the specified mail box address and performs a configurable read or write of a configurable size. Because each interrupt requires only a single bus address, there is no meaningful limit on the number of processors that can use mailbox interrupts. Most modern processor boards include some kind of mailbox interrupt.

Each processor must tell the other processors which notification method it uses. Each processor enters its interrupt type and up to three related parameters in the shared-memory data structures. The shared-memory backplane network drivers of the other processors use this information when sending packets.

The interrupt type and parameters for each processor are specified during configuration. The relevant configuration parameter is SM_INT_TYPE (also SM_INT_ARGn). The possible values are defined in the header file smLib.h. Table 3-1 summarizes the available interrupt types and parameters.

Table 3-1 : Backplane Interrupt Types

Type

Arg 1

Arg 2

Arg 3

Description

SM_INT_NONE

Polling

SM_INT_BUS

level

vector

Bus interrupt

SM_INT_MAILBOX_1

address space

address

value

1-byte write mailbox

SM_INT_MAILBOX_2

address space

address

value

2-byte write mailbox

SM_INT_MAILBOX_4

address space

address

value

4-byte write mailbox

SM_INT_MAILBOX_R1

address space

address

1-byte read mailbox

SM_INT_MAILBOX_R2

address space

address

2-byte read mailbox

SM_INT_MAILBOX_R4

address space

address

4-byte read mailbox

SM_INT_USER_1

user defined

first user-defined method

SM_INT_USER_2

user defined

second user-defined method

3.3.3 Sequential Addressing

Sequential addressing is a method of assigning IP addresses to processors on the backplane network based on their processor number. Addresses are assigned in ascending order, with the master having the lowest address, as shown in Figure 3-3.

Figure 3-3 : Sequential Addressing

Using sequential addressing, a target on the shared-memory backplane network can determine its own IP address. Only the master's IP address need be entered manually. All other processors on the backplane determine their IP address by adding their processor number to the master's IP address.

Sequential addressing simplifies network configuration. By explicitly assigning an IP address to the master processor, you implicitly assign IP addresses to other processors. This simplifies setting up the boot parameters, in that only the master's parameters need to specify the backplane network IP address. The boot parameters of the slave processors need no backplane IP addresses. Thus, when setting up a shared-memory backplane network with sequential addressing, choose a block of IP addresses and assign the lowest address in this block to the master.

When the master initializes the shared-memory backplane network driver, the master passes in its IP address as a parameter. The shared-memory backplane network stores this information in the shared-memory region. If any other address is specified in the inet on backplane (b) boot parameter, the specified address overrides the sequential address. To determine the starting IP address for an active shared-memory network, use smNetShow( ), if you are working under Tornado 3, or ifShow("sm") from the master if you are working under Tornado 2.

Tornado 3 Example

In the following example, the master's IP address is 150.12.17.1.

[vxKernel] -> smNetShow

The following output displays on the standard output device:

Anchor Local Addr: 0x4100, Hard TAS 
Sequential addressing enabled. 
Master IP address: 150.12.17.1   Local IP address: 150.12.17.2 
 
heartbeat = 56, header at 0xe0025c, free pkts = 57. 
 
cpu int type    arg1       arg2       arg3    queued pkts 
--- -------- ---------- ---------- ---------- ----------- 
 0  mbox-1          0xd 0xfb000000       0x80       0 
 1  mbox-1          0xd 0xfb001000       0x80       2 
 
             PACKETS                         ERRORS 
    Unicast           Brdcast 
 Input    Output   Input    Output       Input    Output 
=======  =======  =======  =======   +  =======  ======= 
     26       27        2        2   |        0        1 
value = 0 = 0x0 
[vxKernel] ->

With sequential addressing, when booting a slave, the backplane IP address and gateway IP boot parameters are not necessary. The default gateway address is the address of the master. Another address can be specified if this is not the desired configuration.

[vxWorks Boot]   : p 
boot device      : esm=0xD:0x800000 
processor number : 1  
file name        : /folk/fred/wind/target/config/bspname/vxWorks 
host inet (h)    : 150.12.1.159 
user (u)         : moose 
flags (f)        : 0x0  
[vxWorks Boot]   : @ 
 
boot device          : esm 
unit number          : 0  
processor number     : 1  
host name            : host 
file name            :/folk/fred/wind/target/config/bspname/vxWorks 
inet on backplane (b): 150.12.17.2:ffffff00 
host inet (h)        : 150.12.1.159 
user (u)             : moose 
flags (f)            : 0x0  
target name (tn)     : t207-2 
 
Attaching to SM net with memory anchor at 0x10004100... 
SM address: 150.12.17.2 
Attached TCP/IP interface to esm0. 
Gateway inet address: 150.12.17.1 
Attaching interface lo0...done 
Loading /folk/fred/wind/target/config/bspname/vxWorks/boot.txt 
 
sdm0=/folk/fred/wind/target/config/bspname/vxWorks/vxKernel.sdm 
0x000d8ae0 + 0x00018cf0 + 0x00011f70 + (0x0000ccec) + 0x00000078 + 0x0000015c

Sequential addressing can be enabled during configuration. The relevant component is INCLUDE_SM_SEQ_ADDR.

Tornado 2 Example

In the following example, the master's IP address is 150.12.17.1.

[vxKernel] -> ifShow("sm")

The following output displays on the standard output device:

sm (unit number 0): 
    Flags: (0x8063) UP BROADCAST MULTICAST ARP RUNNING 
    Type: ETHERNET_CSMACD 
    Internet address: 147.11.207.1 
    Broadcast address: 147.11.207.255 
    Netmask 0xffff0000 Subnetmask 0xffffff00 
    Ethernet address is 00:02:e2:00:00:00 
    Metric is 0 
    Maximum Transfer Unit size is 2178 
    0 packets received; 1 packets sent 
    0 multicast packets received 
    0 multicast packets sent 
    0 input errors; 0 output errors 
    0 collisions; 0 dropped 
value = 29= 0x1d 
[vxKernel] ->

[vxWorks Boot]: p 
boot device      : sm=0x800000 
processor number : 1  
file name        : /folk/fred/wind/target/config/bspname/vxWorks 
host inet (h)    : 150.12.1.159 
user (u)         : moose 
flags (f)        : 0x0  
[vxWorks Boot]: @ 
 
boot device          : sm 
unit number          : 0  
processor number     : 1  
host name            : host 
file name            :/folk/fred/wind/target/config/bspname/vxWorks 
inet on backplane (b): 150.12.17.2:ffffff00 
host inet (h)        : 150.12.1.159 
user (u)             : moose 
flags (f)            : 0x0  
target name (tn)     : t207-2 
 
Backplane anchor at 0x10004100... Attaching network interface sm0... done 
Attaching interface lo0...done 
Loading... 950064 
Starting at 0x100000,,,

Sequential addressing can be enabled during configuration. The relevant component is INCLUDE_SM_SEQ_ADDR.

3.3.4 Shared-Memory Backplane Network Configuration

For UNIX, configuring the host to support a shared-memory backplane network uses the same procedures outlined elsewhere for other types of networks. In particular, a shared-memory backplane network requires that:

All shared-memory backplane network host names and addresses are present in /etc/hosts.

All shared-memory backplane network host names are present in .rhosts in your home directory or in /etc/hosts.equiv if you are using RSH.

A gateway entry specifies the master's Internet address on the external network as the gateway to the shared-memory backplane network. The gateway entry is not needed if you are using proxy ARP. For more information, see 4.8 Proxy ARP for Transparent Subnets, p.81.

For Windows hosts, the steps required to configure the host are determined by your version of Windows and the networking software you are using. See that documentation for details.

Example Configuration

This section presents an example of a simple shared-memory backplane network. The network contains a single host and two target processors on a single backplane. In addition to the target processors, the backplane includes a separate memory board for the shared-memory region, and an Ethernet controller board. The additional memory board is not essential, but provides a configuration that is easier to describe.

Figure 3-4 illustrates the overall configuration. The Ethernet network is assigned network number 150, subnet 12.0, and the shared-memory backplane network is assigned network number 161, subnet 27.0. The host h1 is assigned the Internet address 150.12.0.1.

Figure 3-4 : Example Shared-Memory Backplane Network

The shared memory master is vx1, and functions as the gateway between the Ethernet and shared-memory backplane networks. It therefore has two Internet addresses: 150.12.0.2 on the Ethernet network and 161.27.0.1 on the shared-memory backplane network.

The other backplane processor is vx2; it is assigned the shared-memory backplane network address 161.27.0.2. It has no address on the Ethernet because it is not directly connected to that network. However, it can communicate with h1 over the shared-memory backplane network, using vx1 as a gateway. Of course, all gateway use is handled by the IP layer and is completely transparent to the user. Table 3-2 shows the example address assignments.

Table 3-2 : Network Address Assignments


Name	Inet on Ethernet	Inet on Backplane

h1	150.12.0.1	-
vx1	150.12.0.2	161.27.0.1
vx2	-	161.27.0.2

To configure the UNIX system for our example, the /etc/hosts file must contain the Internet address and name of each system. Note that the backplane master has two entries. The second entry, vx1.sm, is not actually necessary. This is because the host system never accesses that system with that address. Still, it is useful to include it in the file because that ensures that the address is not used for some other purpose.

The entries in /etc/hosts are as follows:

150.12.0.1    h1 
150.12.0.2    vx1 
161.27.0.1    vx1.sm 
161.27.0.2    vx2

To allow remote access from the target systems to the UNIX host, the .rhosts file in your home directory, or the file /etc/hosts.equiv, must contain the names of the target systems:

vx1 
vx2

To inform the UNIX system of the existence of the Ethernet-to-shared-memory backplane network gateway, make sure the following line is in the file /etc/gateways at the time the route daemon routed is started.

net 161.27.0.0 gateway 150.12.0.2 metric 1 passive

Alternatively, you can add the route manually (effective until the next reboot) with the following UNIX command:

% route add net 161.27.0.0 150.12.0.2 1

To prepare a run-time image for vx1, the backplane master shown in Figure 3-4, include the following configuration components:

Tornado 3

INCLUDE_SMEND -- includes the shared memory END (smEnd)

INCLUDE_SM_COMMON -- includes configuration parameters common to memory sharing utilities

INCLUDE_SECOND_SMEND_BOOT -- attaches the smEnd as a secondary boot device

SM_OFF_BOARD -- included because the memory is physically off-board

Within the INCLUDE_SMEND and INCLUDE_SM_COMMON components, you must set the parameters as shown in Table 3-3.

Table 3-3 : Configuration Parameters from INCLUDE_SM_COMMON and INCLUDE_SMEND

Parameter¹

Value

Comment

SM_NET_DEV_NAME

"esm"

The name of the device.

SM_ADRS_SPACE

0xD
e.g., esm=0xD:0x800000

Address space of shared-memory region as seen by vx1.

SM_ANCHOR_ADRS

0x800000
e.g., esm=0xD:0x800000

Address of anchor as seen by vx1 in SM_ADRS_SPACE.

SM_NET_MEM_SIZE

0x80000

Size of the shared-memory network area, in bytes.

SM_OBJ_MEM_SIZE

(set to zero if not used)

Size of the shared-memory object area, in bytes.

SM_INT_TYPE

SM_INT_MAILBOX_1

Interrupt targets with 1-byte write mailbox.

SM_INT_ARG1

VME_AM_SUP_SHORT_IO

Mailbox in short I/O space.

SM_INT_ARG2

(0xc000| 
(sysProcNum * 2))

Mailbox at:
0xc000 for vx1
0xc002 for vx2

SM_INT_ARG3

Write 0 value to mailbox.

SM_PKTS_SIZE

DEFAULT_PKTS_SIZE

Shared memory packet size.

SM_CPUS_MAX

DEFAULT_CPUS_MAX

Maximum number of CPUs for the shared network.

1: The SM_PKTS_SIZE and SM_CPUS_MAX parameters are part the INCLUDE_SMEND configuration component. The other parameters are in INCLUDE_SM_COMMON.

Tornado 2

INCLUDE_SM_NET --includes the shared memory driver (if_sm)

INCLUDE_SM_COMMON--includes configuration parameters common to memory sharing utilities

INCLUDE_SECOND_SMNET--attaches the if_sm as a secondary boot device

INCLUDE_SM_NET_SHOW--includes the smNetShow( ) routine

Within the INCLUDE_SM_NET and INCLUDE_SM_COMMON components, you must set the parameters as shown in Table 3-4.

Table 3-4 : Configuration Parameters from INCLUDE_SM_COMMON and INCLUDE_SM_NET

Parameter¹

Value

Comment

SM_OFF_BOARD

TRUE

shared memory is on separate board

SM_ANCHOR_ADRS

0x800000
e.g., sm=0x800000

Address of anchor as seen by local CPU.

SM_MEM_SIZE

0x80000

Size of the shared-memory backplane network area, in bytes.

SM_OBJ_MEM_SIZE

(set to zero if not used)

Size of the shared-memory object area, in bytes.

SM_INT_TYPE

SM_INT_MAILBOX_1

Interrupt targets with 1-byte write mailbox.

SM_INT_ARG1

VME_AM_SUP_SHORT_IO

Mailbox in short I/O space.

SM_INT_ARG2

(0xc000| 
(sysProcNum * 2))

Mailbox at:
0xc000 for vx1
0xc002 for vx2

SM_INT_ARG3

Write 0 value to mailbox.

SM_PKTS_SIZE

DEFAULT_PKTS_SIZE

Shared memory packet size.

SM_CPUS_MAX

DEFAULT_CPUS_MAX

Maximum number of CPUs for the shared network.

1: The SM_PKTS_SIZE and SM_CPUS_MAX parameters are part the INCLUDE_SM_NET configuration component. The other parameters are in INCLUDE_SM_COMMON.

When booting the backplane master, vx1, specify boot line parameters such as the following:

boot device             : gn 
processor number        : 0 
host name               : h1 
file name               : /usr/wind/target/config/bspname/vxWorks 
inet on ethernet (e)    : 150.12.0.2 
inet on backplane (b)   : 161.27.0.1:ffffff00 
host inet (h)           : 150.12.0.1 
gateway inet (g)        : 
user (u)                : darger 
ftp password (pw) (blank=use rsh) : 
flags (f)               : 0

NOTE: For more information on boot devices, see the Tornado User's Guide: Getting Started. To determine which boot device to use, see the BSP's documentation.

The other target, vx2, would use the following boot parameters:⁴

Under Tornado 3:

boot device             : esm 
processor number        : 1 
host name               : h1 
file name               : /usr/wind/target/config/bspname/vxWorks 
inet on ethernet (e)    :  
inet on backplane (b)   : 161.27.0.2 
host inet (h)           : 150.12.0.1 
gateway inet (g)        : 161.27.0.1 
user (u)                : darger 
ftp password (pw) (blank=use rsh):  
flags (f)               : 0

Under Tornado 2:

boot device             : sm 
processor number        : 1 
host name               : h1 
file name               : /usr/wind/target/config/bspname/vxWorks 
inet on ethernet (e)    :  
inet on backplane (b)   : 161.27.0.2 
host inet (h)           : 150.12.0.1 
gateway inet (g)        : 161.27.0.1 
user (u)                : darger 
ftp password (pw) (blank=use rsh):  
flags (f)               : 0

Troubleshooting

Getting a shared-memory backplane network configured for the first time can be tricky. If you have trouble, use the following troubleshooting procedures--taking one step at a time.

Boot a single processor in the backplane without any additional memory or processor cards.

Power off and add the memory board, if you are using one. Power on and boot the system again. Using the VxWorks boot ROM commands for display memory (d) and modify memory (m), verify that you can access the shared memory at the address you expect, with the size you expect.

Reboot the system, filling in the inet on backplane parameter. This initializes the shared-memory backplane network. The following message appears during the reboot:

Under Tornado 3:

Backplane anchor at anchor-addrs...Attaching network interface esm...done.

Under Tornado 2:

Backplane anchor at anchor-addrs...Attaching network interface sm...done.

After VxWorks is booted, you can display the state of the shared-memory network with the smNetShow( ) routine, as follows:

-> smNetShow ["interface"] [, 1] 
value = 0 = 0x0

Under Tornado 3, the interface parameter is esm by default. Under Tornado 2, it is sm0. Normally, smNetShow( ) displays cumulative activity statistics to the standard output device; specifying 1 (one) as the second argument resets the totals to zero.

Now test the host connection to the shared-memory master by pinging both of its IP addresses from the host. On the host console , type:

ping 150.12.0.2

This should succeed and produce a message something like:

150.12.0.2 is alive

Then type:

ping 161.27.0.1

This should also succeed. If either ping fails, the host is not configured properly, or the shared-memory master has incorrect boot parameters.

Power off and add the second processor board. Remember that the second processor must not be configured as the system controller board. Power on and stop the second processor from booting by typing any key to the boot ROM program. Boot the first processor as you did before.

If you have trouble booting the first processor with the second processor plugged in, you have some hardware conflict. Check that only the first processor board is the system controller. Check that there are no conflicts between the memory addresses of the various boards.

On the second processor's console, use the d and m boot ROM commands to verify that you can see the shared memory from the second processor. This is either the memory of the separate memory board (if you are using the off-board configuration) or the dual-ported memory of the first processor (if you are using the on-board configuration).

Use the d command on the second processor.

Under Tornado 3, use the d command to look for the local address of the shared-memory anchor as mapped to the two-part bus address space and anchor location within that space. You can also look for the shared-memory heartbeat; see The Shared-Memory Backplane Network Heartbeat, p.25.

Under Tornado 2, use the d command on the second processor to look for the shared-memory anchor. You can also look for the shared-memory heartbeat; see The Shared-Memory Backplane Network Heartbeat, p.25.

After you have found the anchor from the second processor, enter the boot parameter for the boot device with the appropriate anchor bus address:

Under Tornado 3, enter the two-part backplane bus anchor address:

boot device: esm=0x0d:0x10010000

Under Tornado 2, enter the local bus anchor address:

boot device: sm=0x10010000

Enter the other boot parameters and try booting the second processor.

If the second processor does not boot, you can use smNetShow( ) on the first processor to see if the second processor is correctly attaching to the shared-memory backplane network. If not, then you have probably specified the anchor bus address incorrectly on the second processor or have a mapping error between the local and backplane buses. If the second processor is attached, then the problem is more likely to be with the gateway or with the host system configuration.

You can use host system utilities, such as arp, netstat, etherfind, and ping, to study the state of the network from the host side; see the Tornado User's Guide: Getting Started.

If all else fails, call your technical support organization.

3.4 Custom Interfaces

You can write a driver to provide a custom interface to existing or new communication media. If you write the driver to use the MUX/END interface, the VxWorks network stack can use your custom interface as readily as it uses the Ethernet interface.

1: For more information on the MUX and on END and NPT drivers, see 10. Integrating a New Network Interface Driver.

2: The backplane is a type of bus. In this document, the terms are used interchangeably.

3: Or a close approximation to it. Some hardware cannot generate RMW cycles on the VME bus and the PCI bus does not support them at all.

4: The parameters inet on backplane (b) and gateway inet (g) are optional with sequential addressing.