WR VX Simulator Users Guide 6.9

Wind River VxWorks Simulator User's Guide, 6.
Wind River VxWorks Simulator
USER'S GUIDE
6.9
Copyright 2010 Wind River Systems, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means without the prior written permission of Wind River Systems, Inc. Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see: www.windriver.com/company/terms/trademark.html This product may include software licensed to Wind River by third parties. Relevant notices (if any) are provided in your product installation at the following location: installDir/product_name/3rd_party_licensor_notice.pdf. Wind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.
Corporate Headquarters Wind River 500 Wind River Way Alameda, CA 94501-1153 U.S.A. Toll free (U.S.A.): 800-545-WIND Telephone: 510-748-4100 Facsimile: 510-749-2010
For additional contact information, see the Wind River Web site: www.windriver.com For information on how to contact Customer Support, see: www.windriver.com/support
Wind River VxWorks Simulator User's Guide 6.9
15 Dec 10
Contents
Overview ......................................................................................................
1.1 1.2 Introduction ...................................................................................................................... Supported Features and Compatibility ...................................................................... 1.2.1 1.2.2 1.3 VxWorks Feature Support ............................................................................... Simulated Hardware Support .........................................................................
1
1 2 2 3 3
Limitations ........................................................................................................................
Getting Started ............................................................................................

2.1 2.2 Introduction ...................................................................................................................... System Requirements ..................................................................................................... Multiprocessor Simulation Requirements ..................................................... 64-Bit Support .................................................................................................... 2.3 Configuring and Building a VxWorks Image ............................................................ 2.3.1 2.3.2 2.3.3 2.3.4 2.4 Default Configuration Components ............................................................... Configuring Optional Components ............................................................... Building Your VxWorks Image ....................................................................... VxWorks Source Build (VSB) Projects ............................................................
5
5 5 5 6 6 6 7 7 8 8 8 12 12 13 13 14 14
Launching the VxWorks Simulator ............................................................................. 2.4.1 2.4.2 vxsim Configuration Options .......................................................................... Launching a VxWorks Simulator Instance from the Command Line ....... Modifying the Windows Simulator Console Appearance .......................... Starting an Instance with Network Redirection (NAT) ............................... Starting an Instance to Run on a Simulated Subnet ..................................... 2.4.3 2.4.4 Launching the VxWorks Simulator from Workbench ................................. Connecting to an Existing Simulator Instance from Workbench ...............
iii
Wind River VxWorks Simulator User's Guide, 6.9
2.4.5 2.4.6
Rebooting and Exiting the VxWorks Simulator ........................................... Accessing the VxWorks Simulator from a Remote Host .............................
15 15
Introduction to the VxWorks Simulator Environment .............................

3.1 3.2 3.3 Introduction ...................................................................................................................... The VxWorks Simulator BSP ........................................................................................ Building Applications .................................................................................................... 3.3.1 3.3.2 3.4 Defining Compiler Options ............................................................................. Compiling Modules for Debugging ...............................................................
17
17 17 18 18 20 21 21 21 22 22 22 22 23 23 23 23 23 23 24 24 24 24 25 25 25 26 28
Interface Variations ........................................................................................................ 3.4.1 Memory Management Unit ............................................................................. Simulation .......................................................................................................... Translation Model ............................................................................................. Page Size ............................................................................................................. Limitations ......................................................................................................... Running the VxWorks Simulator Without MMU Support ......................... 3.4.2 3.4.3 RTP Considerations .......................................................................................... File System Support .......................................................................................... Pass-Through File System (passFS) ................................................................ Virtual Disk Support ......................................................................................... 3.4.4 3.4.5 WDB Back End .................................................................................................. Connection Timeout .........................................................................................
3.5
Architecture Considerations ......................................................................................... 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 Byte Order ......................................................................................................... Hardware Breakpoint ....................................................................................... Floating-Point Support ..................................................................................... ISR Stack Protection .......................................................................................... Interrupts ........................................................................................................... Solaris and Linux Systems ............................................................................... Windows Systems ............................................................................................ 3.5.6 Memory Layout ................................................................................................
Using the VxWorks Simulator ...................................................................

4.1 4.2 Introduction ...................................................................................................................... Configuring the VxWorks Simulator .......................................................................... 4.2.1 4.2.2 Boot Parameters ................................................................................................ Memory Configuration ...................................................................................
33
33 33 33 34
iv
Contents
Physical Memory Address Space .................................................................... Virtual Memory Address Space (32-Bit VxWorks Simulator) .................... Virtual Memory Address Space (64-Bit VxWorks Simulator) .................... User Shared Memory ........................................................................................ Memory Protection Level ................................................................................ 4.2.3 4.3 Miscellaneous Configuration ..........................................................................
34 35 35 35 36 37 37 37 38 39 39 39 40 40 40 42 43 44 44 45 45 45
Configuring Hardware Simulation ............................................................................ 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 Pass-Through File System (passFS) ................................................................ Virtual Disk Support ........................................................................................ Non-Volatile RAM Support ............................................................................ Standard I/O ..................................................................................................... Timers ................................................................................................................ Timestamp Driver ............................................................................................ Serial Line Support .......................................................................................... Shared Memory Network ................................................................................
4.4
Using VxWorks SMP with the VxWorks Simulator ................................................ 4.4.1 Creating an SMP Image ....................................................................................
4.5
64-Bit VxWorks Simulation ........................................................................................... 4.5.1 4.5.2 Creating a 64-Bit Image .................................................................................... Large Code Model .............................................................................................
4.6 4.7
Migrating Applications to a Hardware-Based System ........................................... Using a Telnet Client to Display the Simulator Console ........................................
Networking with the VxWorks Simulator ..................................................

5.1 5.2 Introduction ...................................................................................................................... Full Network Simulation: simnet ................................................................................ 5.2.1 5.2.2 Building Network Simulations ....................................................................... Setting Up the Network Daemon ................................................................... Starting the Network Daemon as a Service ................................................... Starting the Network Daemon from the Command Line .......................... Removing the Network Daemon Service ..................................................... Network Daemon Debug Shell ...................................................................... Creating a Network Daemon Configuration File ........................................ 5.2.3 Installing the Host Connection Driver .......................................................... 32-Bit Windows Hosts ..................................................................................... 64-Bit Windows Hosts ...................................................................................... Solaris Hosts ...................................................................................................... Linux Hosts ....................................................................................................... Managing the WRTAP Driver on Windows Hosts ......................................
47
47 48 48 50 51 55 57 57 59 63 64 65 66 66 67
5.2.4
Configuring a Simulated Subnet .................................................................... Starting a Simulator Instance with Multiple Network Interfaces .............. Starting a Simulator Instance without an IPv4 Address .............................
68 68 69 69 71 71 72 72 72 73 73 74
5.2.5 5.3
Configuring a Subnet Across Multiple Hosts Using wrnetdlink ...............
Network Redirection: simnet_nat ................................................................................ 5.3.1 Using Default Redirections .............................................................................. Overriding Default Redirections .................................................................... 5.3.2 Adding a Network Redirection ....................................................................... From the Command Line ................................................................................. From Workbench ............................................................................................... 5.3.3 5.3.4 Listing Network Redirections ......................................................................... Limitations .........................................................................................................
Networking Tutorials ..................................................................................

6.1 6.2 Introduction ...................................................................................................................... Simple Simulated Network .......................................................................................... 6.2.1 6.2.2 6.2.3 6.3 Set Up the Network Daemon .......................................................................... Start a VxWorks Simulator Instance ............................................................... Test the Simulated Network ............................................................................
75
75 76 76 77 79 79 80 86 89 89 90 92 92 93 93 93 94 95 95 97 97 98
Basic Simulated Network with Multiple Simulators ............................................... 6.3.1 6.3.2 Creating a Static Configuration ....................................................................... Creating a Dynamic Configuration Using the vxsimnetd Shell .................
6.4
Networking Across Multiple Hosts with wrnetdlink .............................................. 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 Set Up the Network Daemon on Each Host .................................................. Configure a VxWorks Image on Each Host .................................................. Start a Simulator Instance on Each Host ........................................................ Connect the Simulated Subnets Using wrnetdlink ...................................... Test the Simulated Network ............................................................................
6.5
Adding a VxWorks Simulator to a Local Network ................................................... 6.5.1 6.5.2 Default Subnet Configuration ......................................................................... Configuring a Bridge ........................................................................................ Windows Hosts ................................................................................................. Linux Hosts ........................................................................................................
6.6
IPv6 Tutorial ..................................................................................................................... 6.6.1 6.6.2 Configure the Network .................................................................................... Configuring VxWorks with IPv6 Components ...........................................
vi
Contents
Build Your Projects ........................................................................................... 6.6.3 Testing the IPv6 Connection ............................................................................ Start the VxWorks Simulator Instances .........................................................
99 99 99
Tutorial: Simulating VxWorks AMP ........................................................... 105

7.1 7.2 Introduction ...................................................................................................................... 105 Tutorial: Simulating AMP ............................................................................................. 105 7.2.1 Create and Build a VxWorks Image Project for Simulating the Primary CPU 106 Workbench ......................................................................................................... 106 Command Line .................................................................................................. 108 7.2.2 Create and Build VxWorks Image Projects for Simulating Secondary CPUs 109 Workbench ......................................................................................................... 109 Command Line .................................................................................................. 110 7.2.3 Start the VxWorks Simulation of the Primary CPU ..................................... 112 Workbench ......................................................................................................... 112 Command Line .................................................................................................. 112 7.2.4 7.2.5 7.2.6 7.2.7 Start the VxWorks Simulation of a Secondary CPU .................................... 112 Verifying Connectivity Using the mipcShowBus Command ..................... 113 Run the MIPC Demo Application ................................................................... 114 Configure MND Devices and Confirm Connectivity .................................. 114
Accessing Host Resources ....................................................................... 117

A.1 A.2 A.3 A.4 Introduction ...................................................................................................................... 117 Accessing Host OS Routines ........................................................................................ 118 Loading a Host-Based Application .............................................................................. 118 Host Application Interface (vxsimapi) ........................................................................ 118 A.4.1 A.4.2 A.4.3 A.5 Defining User Exit Hooks ................................................................................ 119 Configuring a Host Device to Generate interrupts (UNIX Only) .............. 119 Simulating interrupts From a User Application (Windows Only) ............ 120
Tutorials and Examples .................................................................................................. 120 A.5.1 Running Tcl on the VxWorks Simulator ........................................................ 120 Code Sample ...................................................................................................... 121 Running The Code ............................................................................................ 122 A.5.2 Controlling a Host Serial Device ..................................................................... 122
vii
VxWorks Simulator Exceptions ................................................................. 123

B.1 B.2 B.3 Introduction ...................................................................................................................... 123 Simulator Exceptions for Windows ............................................................................. 123 Simulator Exceptions for UNIX-Based Operating Systems .................................... 124
Index ..................................................................................................................... 125
viii
1
Overview
1.1 Introduction 1 1.2 Supported Features and Compatibility 2 1.3 Limitations 3
1.1 Introduction
The Wind River VxWorks Simulator is a simulated hardware target for use as a prototyping and test-bed environment for VxWorks. The VxWorks simulator allows you to develop, run, and test VxWorks applications on your host system, reducing the need for target hardware during development. The VxWorks simulator also allows you to set up a simulated target network for developing and testing complex networking applications. For external applications needing to interact with a VxWorks target, the capabilities of a VxWorks simulator instance are identical to those of a VxWorks system running on target hardware. A VxWorks simulator instance supports a standard set of VxWorks features, such as network applications and target and host VxWorks shells. Building these features into a VxWorks simulator image is no different than building them into any VxWorks cross-development environment using a standard board support package (BSP). The goal of this document is to quickly familiarize you with the VxWorks simulator. The early chapters discuss basic configuration information, instructions for building a VxWorks image based on the VxWorks simulator BSP, instructions for launching the VxWorks simulator from Wind River Workbench or the command line, and information on building applications. Later chapters provide more detailed usage information as well as instructions and tutorials for setting up a network of VxWorks simulator instances. This document provides instructions for all supported VxWorks simulator host types including Linux, Solaris, and Windows-based simulators.
NOTE: Many examples in this document are provided generically for all hosts.
These examples are typically provided in UNIX syntax. Be sure to modify the generic examples to suit your host platform. For example, on Windows hosts, be sure to change forward slashes to backslashes in file paths.
1.2 Supported Features and Compatibility

The VxWorks simulator supports most VxWorks features available on target hardware and also provides support for a number of simulated hardware devices. In addition, applications developed for the simulator are fully compatible with VxWorks.
1.2.1 VxWorks Feature Support

Applications developed using the VxWorks simulator can take advantage of the following VxWorks features:
Error Detection and Reporting ISR Stack Protection (Solaris and Linux hosts only) MIPC Overlapped Memory Real-Time Processes (RTPs) ROMFS Shared Data Regions Shared Libraries (Windows and Linux hosts only) VxFusion (distributed message queues) VxMP (shared-memory objects) VxWorks source build (VSB) projects Wind River System Viewer VxWorks Asymmetric Multiprocessing (AMP) Support for 32- and 64-bit hardware platforms
For more information on these features, see the VxWorks Kernel Programmers Guide.
1 Overview 1.3 Limitations
1.2.2 Simulated Hardware Support

To support application development, the VxWorks simulator provides simulated hardware support for the following hardware-related features:
a VxWorks console a system timer a memory management unit (MMU)MMU support is required to take advantage of the VxWorks real-time process (RTP) feature. non-volatile RAM (NVRAM) virtual disk supportVirtual disk support allows you to simulate a disk block device. The simulated disk block device can then be used with any file system supported by VxWorks. a timestamp driver a real-time clock symmetric multiprocessing (SMP) environment asynchronous multiprocessing (AMP) environment
For information on including support for these simulated hardware features in your VxWorks image, see 2.3 Configuring and Building a VxWorks Image, p.6. For more information on hardware simulation, see 4.3 Configuring Hardware Simulation, p.37.
1.3 Limitations
The VxWorks simulator is not suitable for all prototyping needs. The VxWorks simulator executes on the host machine and does not attempt the simulation of machine-level instructions for a target architecture. For this reason, the VxWorks simulator is not a suitable basis on which to develop hardware device drivers. However, the VxWorks simulator includes MMU support and implements the architecture-specific part of a memory management unit in order to provide the same level of feature support as hardware-based targets.
SMP
SMP simulation using the VxWorks simulator is more accurate if the host machine provides multiple CPU cores.
NOTE: If your host system supports hyperthreading, this can also be used to improve SMP simulation. 64-Bit VxWorks
The 64-bit VxWorks simulator is supported on 64-bit host operating systems only. Solaris is not supported as a host OS for the 64-bit VxWorks simulator.
2
Getting Started
2.1 Introduction 5 2.2 System Requirements 5 2.3 Configuring and Building a VxWorks Image 6 2.4 Launching the VxWorks Simulator 8
2.1 Introduction
This chapter briefly describes how to set up and configure standard features in a VxWorks image for use with the VxWorks simulator. It also includes instructions for launching the VxWorks simulator from your development environment. For more information on configuring and building VxWorks, see the VxWorks Kernel Programmers Guide, Wind River Workbench By Example, and the users guide for your Platform product.
2.2 System Requirements

Host system requirements for the VxWorks simulator are the same as those of a standard VxWorks installation; no additional resources are required. For information on VxWorks host system requirements, see your Platform release notes.
Multiprocessor Simulation Requirements
SMP simulations are more accurate if the host machine provides the same number of CPU cores as the hardware target.
64-Bit Support
To simulate 64-bit VxWorks, you must run the VxWorks simulator on a 64-bit host. Your 64-bit host operating system must be a supported version of Windows or Linux. Solaris is not supported as a host OS for 64-bit simulation.
2.3 Configuring and Building a VxWorks Image

The default configuration file included in the VxWorks simulator BSP produces a full-featured VxWorks image. Many standard VxWorks features are included in the image by default. In addition to a list of default configuration components, this section provides configuration information for supported optional components as well as basic instructions for building a VxWorks image.
2.3.1 Default Configuration Components

The VxWorks simulator default configuration includes support for many VxWorks features, including:
basic memory management support (INCLUDE_MMU_BASIC) (See 3.4.1 Memory Management Unit, p.21.) C++ support error detection and reporting features kernel hardening features (such as text segment write protection) kernel shell (and its C and command interpreters) network stack non-volatile RAM (See 4.3.3 Non-Volatile RAM Support, p.39.) POSIX support (limited support in default configuration) real-time process (RTP) support ROM-based file system (ROMFS) shared libraries and shared data regions spy (task monitoring) virtual disk support (See 4.3.2 Virtual Disk Support, p.38.) Wind River System Viewer
For more information on these features, see the VxWorks Kernel Programmers Guide and the VxWorks Application Programmers Guide. For information on using these features with the VxWorks simulator, see 4. Using the VxWorks Simulator.
2 Getting Started 2.3 Configuring and Building a VxWorks Image
NOTE: Networking for the VxWorks simulator is configured by default. However, the network is only automatically enabled if a network device (simnet or simnet_nat) is enabled. For VxWorks 6.9 connections, Workbench does this by default. Otherwise, you can choose the network device in either of the following ways:
through the Target Connection Properties on the Network Options tab through the command-line options (-d or -ni).
For more information on these options, see 2.4.1 vxsim Configuration Options, p.8.
2.3.2 Configuring Optional Components

The VxWorks simulator provides optional support for the following VxWorks features. To take advantage of these features, you must configure and build a new VxWorks image for the VxWorks simulator. For more information on building and configuring a VxWorks image, see 2.3.3 Building Your VxWorks Image, p.7.
VxMP
The VxWorks simulator optionally supports the multiprocessor capabilities available using the VxWorks VxMP feature. To include support for this feature, you must include the INCLUDE_SM_COMMON, INCLUDE_BOOT_LINE_INIT, and INCLUDE_SM_OBJ components in your VxWorks image. To tune the shared memory size allocated for VxMP (default: 8 KB), use the SM_MEM_SIZE parameter. To modify the shared memory pool size assigned to shared objects, change the SM_OBJ_MEM_SIZE parameter.
Shared Memory END Driver
The VxWorks simulator optionally includes shared memory END driver support (smEnd). To include smEnd driver support, the macro INCLUDE_SM_NET must be defined in the BSP configuration. To define the smEnd driver IP address, use the following VxWorks simulator command-line option:
% vxsim -b backplaneAddress
or:
% vxsim -backplane backplaneAddress
2.3.3 Building Your VxWorks Image

The process for configuring and building a VxWorks image is the same for the VxWorks simulator as it is for target hardware. The VxWorks simulator BSP is comparable to a standard VxWorks BSP for a hardware target architecture and uses a standard VxWorks Makefile. However, the BSP makefile builds only the images vxWorks and vxWorks.st (standalone VxWorks). Your VxWorks image can be built using either the Wind River Diab Compiler or the Wind River GNU Compiler. To build a default VxWorks image, create a VxWorks image project as described in the users guide for your Platform. Base your project on the appropriate
VxWorks simulator BSP for your host type. Table 2-1 lists the available simulator BSPs.
Table 2-1 VxWorks Simulator BSPs
Host Type
BSP Name
Windows Solaris Linux
simpc solaris linux
You can also build a VxWorks image project from the command line using the command-line project facility, vxprj. For more information on building a VxWorks image project using vxprj, see the users guide for your Platform product.
2.3.4 VxWorks Source Build (VSB) Projects

The process for configuring and building VSB projects is the same for the VxWorks simulator as it is for target hardware. For more information on VSB projects, see the VxWorks Kernel Programmers Guide: VxWorks Configuration.
2.4 Launching the VxWorks Simulator

This section provides information on launching the VxWorks simulator from your development environment.
NOTE: On Solaris simulators, your path environment variable must include /usr/openwin/bin so that your host can locate xterm. If xterm is not in your path, your VxWorks simulator connection will fail.
2.4.1 vxsim Configuration Options

The vxsim executable provides the equivalent functionality of a boot load program. However, you cannot build or customize vxsim as you can other boot loaders. You can use vxsim to load an image from the VxWorks simulator BSP directory. The vxsim utility supports a set of command-line configuration options that you can use to specify the boot line parameters for the image that will be loaded. The command-line interface also supports additional convenience options that let you handle things such as configuring multiple interfaces for the VxWorks simulator instance. Use vxsim -help to see a complete list of supported options.
NOTE: To preserve boot line parameters after a reboot, you must use the
bootChange( ) routine. This routine is executed in the kernel shell. For more information, see 4.2.1 Boot Parameters, p.33.
2 Getting Started 2.4 Launching the VxWorks Simulator
Table 2-2
Command-Line Options for the VxWorks Simulator
VxWorks Simulator Option
Description
-add_dev serial0=telnet:[portNumber]: [nowait],[nokill]
Launches an instance of the VxWorks simulator that makes its console available over a Telnet server. For a discussion of its usage and an explanation of its optional parameters, see 4.7 Using a Telnet Client to Display the Simulator Console, p.45. Add a NAT network redirection. For details on the syntax and usage of this option, see 5.3.2 Adding a Network Redirection, p.72. The backplane address of the target system. The type of device to boot from: passDev, simnet, or simnet_nat. The default is passDeva. The Internet address to assign to the target system (the boot interface). Upon error, exit the VxWorks simulator without prompting for user input. The file containing the VxWorks image to load. If no file is specified, the vxWorks file, if any, in the current directory is loaded. Configuration flags. The default is 0. The Internet address of the gateway. Print a help message listing the command-line options. The host Internet address. The host machine to boot from. The default value for this option on a Windows system is host. On a UNIX system, the default value is always the actual host name. Kills the VxWorks simulator referenced by processNumber.
-add_nat_redir networkRedirection -anr -backplane inetOnBackplane -b inetOnBackplane -device bootDevice -d bootDevice -ethernet inetOnEthernet -e inetOnEthernet -exitOnError -file fileName -f fileName -flags flags -gateway gatewayInet -g gatewayInet -help -hostinet hostInet -h hostInet -hostname hostName -hn hostName -kill processNumber -k processNumber
Table 2-2
Command-Line Options for the VxWorks Simulator (contd)
Description
-list_dev serial0 -list_dev all
In the current release, this option provides the port number used by the Telnet server for the current instance of the VxWorks simulator (see the table entry for the -add_dev option). Currently, both forms of the option are equivalent, because only a serial device used for displaying the console over Telnet is supported. On UNIX, the port number is displayed on the standard output. On Windows, the VxWorks simulator is not a console application, and simulator output is not displayed on the standard output. To obtain the port number, you need to use -list_dev with the -l option. This writes the port number to the log file specified with -l. Examples:
% vxsim...-list_dev serial0 % vxsim...-l logfile.txt -list_dev serial0 % vxsim...-l list_dev all -p 3 -l logfile.txt -lc
The first example, with no -l option, only applies to UNIX. For more information on the usage of the -list_dev option, see 4.7 Using a Telnet Client to Display the Simulator Console, p.45. -list_nat_redir -lnr -logclean -lc List all NAT network redirections. Clears the log file specified by the -l option. This allows you to start an instance of the VxWorks simulator, clear the log file used by a previous instance, and write new data to it. When the simulator reboots, the log file is also cleared. Enables output logging. Limits the number of CPUs to n. Allows a VxWorks simulator image configured with n CPUs to run with 1 to n CPUs. VxWorks simulator additional network interfaces.b The VxWorks simulator non-volatile RAM file. Unused, available for applications. The users password (for FTP only). Sets the processor number, which is effectively an identifier for this simulator instance. The default value is 0.
-logfile logFile -l logFile -ncpu n -netif additionalInterface -ni additionalInterface -nvram pathToFileForNvram -n -other other -o other -password ftpPassword -pw ftpPassword -processor number -p number
10
Table 2-2
Command-Line Options for the VxWorks Simulator (contd)
Description
-prot-level protectionLevel -pl protectionLevel -size memorySize -memsize memorySize -startup script -s script -targetname targetName -tn targetName -tmpdir directory
Sets the VxWorks simulator memory protection level. Possible values include min (0), max (1), or integer. The default value is max (1). The VxWorks simulator memory size in bytes. The default is 32 MB. A startup script for the kernel shell. The name of the target. The default value is vxsim for the vxsim0 instance; vxsimCpuNum for all other instances. The directory for temporary VxWorks simulator files. The default on a Windows system is the TEMP environment variable value; on a Solaris or Linux system, the default is /tmp. The network device unit number (for the boot interface). The default is 0. The user name used to access the host. Specifies the VxWorks virtual base address. This option is not supported for the 64-bit VxWorks simulator. Specifies the VxWorks virtual memory size. The default is 1 GB. This option is not supported for the 64-bit VxWorks simulator. Print the VxWorks simulator version.
-unit unitNumber -user user -username user -vaddr address -vsize virtualSize -version -v
a. For an actual hardware target, this option is used to specify the device that is used to access the VxWorks image. Because the VxWorks simulator always accesses the VxWorks image from the host file system, this field is used to mimic real target behavior. Specifying simnet or simnet_nat for this option indicates that a simulated boot device should be initialized. In all other cases, passDev is used as the boot device type. For example, the tutorial in 6.3 Basic Simulated Network with Multiple Simulators, p.79 uses the passDev option for the simulated router and the simnet option for each of the simulated network devices. b. Also see the entries for the NAT-related options -add_nat_redir and -list_nat_redir. NOTE: When issuing these command options using the vxsim command from the
command line on a Linux or Solaris host, use double quotation marks around the option values. For example, use vxsim -ni "simnet" in place of vxsim -ni simnet. When launching your VxWorks simulator from Workbench (Target > New Connection > Wind River VxWorks 6.x Simulator Connection), the command-line options listed in Table 2-2 are configured using the New Connection wizard. Certain options (for example, the -ni option) are not available as specific options in the New Connection wizard dialogs. These options can be passed directly to the VxWorks simulator using the Other VxWorks Simulator Options field of the VxWorks Simulator Miscellaneous Options dialog.
11
2.4.2 Launching a VxWorks Simulator Instance from the Command Line

To start a VxWorks simulator instance from the command line, use the vxsim command in the VxWorks Development Shell. Using this command is similar to using a boot program to load an image. As options, vxsim lets you specify values for the parameters typically supplied in a boot line (use vxsim -help to list the option descriptions).
NOTE: You must use the bootChange( ) routine in order to make boot-parameter
changes that survive a reboot. Even if non-volatile RAM support is included, boot parameters will be lost once the simulator is exited because boot parameters are derived from the VxWorks simulator command line. To start a VxWorks simulator using the default configuration values, type the following in the VxWorks Development Shell:
-> vxsim -f pathToVxWorksImage
If you run vxsim from the directory containing the VxWorks image that you want to load, you can type the following:
-> vxsim
If your path does not include vxsim, ensure that your VxWorks environment is properly set. For more information, see the users guide for your Platform product. For the 64-bit VxWorks simulator, use the same command-line sequences as for 32-bit simulation.
Modifying the Windows Simulator Console Appearance
When you launch a VxWorks simulator instance on a Windows host, the target server launches a console connected to the target. To change the font used in the console, right-click the top bar and select Font in the resulting menu. For example, Figure 2-1 shows the simulator console in Windows with the right-click menu open.
Figure 2-1 Simulator Console
12
Starting an Instance with Network Redirection (NAT)
The VxWorks simulator provides a user-mode network stack that acts as a bridge between the guest network stack and the host network stack, without the need for a specific network driver. This type of connection does allow access to network resources, including the Internet. But by default, it acts as a firewall and does not permit any incoming traffic. It also does not support protocols other than TCP and UDP. Therefore, for example, ping and other ICMP utilities do not work with this type of connection. If you want to access a guest UDP/TCP port, the port must be explicitly redirected. To use this kind of simulation, select simnet_nat as your boot device. For example, the following command sequences start two VxWorks simulator instances using the default redirection:
% vxsim -d simnet_nat % vxsim -d simnet_nat -p 1
In the second command sequence above, the -p parameter assigns the value 1 as a processor number to the second VxWorks simulator instance. If you do not specify a -p number, the default value of 0 is applied. For more information on network redirection, see 5.3 Network Redirection: simnet_nat, p.71.
Starting an Instance to Run on a Simulated Subnet
In addition to network redirection, the Wind River VxWorks Simulator also provides a full network simulation environment through the VxWorks simulator network daemon. Unlike the network-redirection method, the daemon allows various protocol and subnet configurations. If you intend to use a simulated subnet in this way, you must start the simulator network daemon before starting a VxWorks simulator instance. (For more information, see 5.2.2 Setting Up the Network Daemon, p.50.) On the whole, you need only concern yourself with those devices related to the network interface specifically, the simnet deviceand its address information (IP address and network mask). If a simulator requires only a single interface, you can specify simnet as the boot device and its IP address using the -e parameter. For example:
% vxsim -d simnet -e 192.168.200.1 % vxsim -d simnet -e 192.168.200.2 -p 1
Assuming the following default subnet:

SUBNET_START default { SUBNET_EXTERNAL = yes; SUBNET_EXTPROMISC = yes; SUBNET_ADDRESS = "192.168.200.0"; };
The two vxsim commands above start two VxWorks simulator instances that attach to the default subnet 192.168.200.0. In the second vxsim command, the -p parameter assigns the value 1 as a processor number to the second VxWorks simulator instance. If you do not specify a -p number, the default value of 0 is applied. A VxWorks simulator instance can also be configured with multiple network interfaces (a router configuration) using the -ni option. For more information on
13
this configuration, see Starting a Simulator Instance with Multiple Network Interfaces, p.68. For more information on setting up a simulated network, see 5.2 Full Network Simulation: simnet, p.48.
2.4.3 Launching the VxWorks Simulator from Workbench

You can launch the VxWorks simulator from Workbench. For step-by-step instructions, see Start the Simulator Instance from Workbench, p.78, in 6. Networking Tutorials. By default, when you launch the VxWorks simulator from Workbench, the simulator console is displayed within Workbench. However, you can change the default and display the console in its own window. To do this: 1. In Workbench, go to: Window > Preferences > Wind River > Target Management > Target Console 2. Uncheck Enable the integrated Target Console for: VxWorks Simulator Connections.
2.4.4 Connecting to an Existing Simulator Instance from Workbench

If you have an existing VxWorks simulator instance running on your host, you can connect to the instance from Workbench just as you would connect to a standard target. To make the connection, do the following: 1. 2. 3. In Workbench, select Target > New Connection... to launch the New Connection wizard. Under the VxWorks 6.x folder, select Wind River VxWorks 6.x Target Server Connection. Click Next. In the Backend settings area of the Target Server Options window, specify the backend type for the VxWorks simulator instance you wish to connect to. (The default VxWorks simulator uses wdbpipe.) In the same window, specify the host name or IP address for the VxWorks simulator instance you wish to connect to. (The host name for the default VxWorks simulator is VxSim0.) Click Finish.
4.
5.
You should now see the connection in the Remote Systems list.
14
2.4.5 Rebooting and Exiting the VxWorks Simulator

As with other targets, you can reboot the VxWorks simulator by typing Ctrl+X in the VxWorks simulator console window. On Windows systems, you can exit the VxWorks simulator by closing the VxWorks simulator window. On Solaris and Linux systems, you must type Ctrl+\ in the VxWorks simulator console window to exit.
NOTE: Issuing the exit command in the kernel shell terminates the shell session
only and cannot be used to exit the VxWorks simulator. To programmatically exit the VxWorks simulator (which may be useful for scripting), you can reboot (BOOT_NO_AUTOBOOT). If you wish to use this option, you must start the VxWorks simulator with the -exitOnError option.
2.4.6 Accessing the VxWorks Simulator from a Remote Host

You can access a VxWorks simulator target from a remote host (a host other than the one running the VxWorks simulator instance). The approach differs, however, according to whether you are using network redirection (simnet_nat) or full network simulation (simnet).
With Network Redirection (simnet_nat)
When you use network redirection through the simnet_nat device, the VxWorks simulator instance can be reached through the host it is running on. For example, if VxWorks telnet port 23 is redirected to host port 12345; and the host has the IP address 10.10.10.1, you would use the following sequence to connect on the VxWorks simulator telnet server:
telnet 10.10.10.1 -p 12345
With Full Network Simulation (simnet)
When you use full network simulation through the simnet device, the simulated subnet is only visible on the host that is running the network daemon and the simulator. To reach the simulator from another host, follow the steps below. 1. Enable IP forwarding on the host that will be running the VxWorks simulator instance.
On Windows hosts, start the Routing and Remote Access service. On Solaris hosts, run the following with root permissions:
# # ndd -set /dev/tcp ip_forwarding 1
On Linux hosts, run the following with root permissions:

$ # echo "1" > /proc/sys/net/ipv4/ip_forward
or, edit /etc/sysconfig/network and add the following line:

FORWARD_IPV4=yes
Then, restart the host. 2. Start a VxWorks simulator instance on an external subnet.
15
3.
Specify the route to access the remote host on the VxWorks simulator instance. The gateway is the address of the host running the VxWorks simulator instance on the simulated subnet (subnetAddress.254). Note that this can be done using VxWorks simulator boot parameters as follows (this example assumes the IP address of the host running the VxWorks simulator instance is 90.0.0.1):
% vxsim -d simnet -e 192.168.200.1 -h 90.0.0.1 -g 192.168.200.254
This sets a route that enables the VxWorks simulator instance to send a packet to any host reachable from 90.0.0.1. 4. On the remote host, specify the route to access the VxWorks simulator instance. The gateway is the address of the host running the VxWorks simulator instance on the remote host subnet.
You can now connect to the VxWorks simulator instance from the remote host.
16
3
Introduction to the VxWorks Simulator Environment
3.1 Introduction 17 3.2 The VxWorks Simulator BSP 17 3.3 Building Applications 18 3.4 Interface Variations 21 3.5 Architecture Considerations 24
3.1 Introduction
This chapter discusses the differences between the VxWorks simulator development environment and the standard VxWorks development environment. In general, the VxWorks simulator environment differs very little from the development environment for any other target hardware system. The most notable differences are the networking methods, which are discussed in 5. Networking with the VxWorks Simulator, and variations in the VxWorks simulator BSP and architecture behavior, which are discussed in the following sections.
3.2 The VxWorks Simulator BSP

Aside from the exceptions noted in this section, the VxWorks simulator BSP is similar to any other VxWorks BSP for a target hardware board and provides similar functionality. For both 32- and 64-bit systems, the VxWorks simulator BSP is almost identical. It uses the same command-line options for both, with the exception of -vaddr and -vsize, which are not available for 64-bit systems.
17
sysLib.c
The sysLib.c module contains the same essential routines: sysModel( ), sysHwInit( ), and sysClkConnect( ) through sysNvRamSet( ). However, because there is no bus, sysBusToLocalAdrs( ) and related routines have no effect in the VxWorks simulator environment. The BSP file sysLib.c can also be extended to emulate the eventual target hardware more completely. For more information on sysLib.c, see the VxWorks BSP Developers Guide: Overview of a BSP.
Standard I/O
The file winSio.c (or unixSio.c for Linux and Solaris systems) ultimately calls the host OS read( ) and write( ) routines on the standard input and output for the process. Nevertheless, it supports all of the functionality provided by tyLib.c.
config.h
The configuration header file, config.h, is minimal:
It does not reference a bspname.h file. The boot line has no fixed memory location. Instead, it is stored in the variable sysBootLine in sysLib.c.
Makefile
The VxWorks simulator Makefile is similar to the standard version used for VxWorks target hardware BSPs. However, it does not build boot ROM images (although the makefile rules remain intact); it can only build vxWorks and vxWorks.st (standalone) images. The final linking does not arrange for the TEXT segment to be loaded at a fixed area in RAM, but follows the usual loading model. The makefile macro MACH_EXTRA is provided so that users can easily link their application modules into the VxWorks image if they are using manual build methods.
3.3 Building Applications

Wind River highly recommends that you build VxWorks simulator modules using the vxprj command-line facility or Wind River Workbench. However, if you wish to customize your build, you may need the information in the following sections.
3.3.1 Defining Compiler Options

The build mechanism for the VxWorks simulator uses two preprocessor constants, CPU and TOOL, to define compiler options for a specific build target. The CPU variable ensures that VxWorks and your applications are compiled with the appropriate features enabled. The TOOL variable defines the toolchain to use for compiling and linking modules.
18
3 Introduction to the VxWorks Simulator Environment 3.3 Building Applications
VxWorks simulator modules can be built with any of these compilers:
the Wind River Diab Compiler the GNU compiler the Intel C++ Compiler for VxWorks
NOTE: For this release of the VxWorks simulator, the Intel C++ Compiler is
supported as an application compiler only. You can use icc to compile kernel modules (DKMs) and RTPs; the VxWorks kernel continues to be built with the GNU compiler. To build modules using the Wind River Diab Compiler, define TOOL as diab. To build modules using the GNU compiler, define TOOL as gnu. To build modules using the Intel C++ Compiler, define TOOL as icc.
NOTE: Modules built with diab, gnu, or icc can be linked together in any
combination, except for modules that require C++ support. Cross-linking of C++ modules is not supported in this release. Applications for the VxWorks simulator can be built to run in either the VxWorks kernel or a VxWorks RTP. Table 3-1 lists the available CPU and TOOL definitions for the VxWorks simulator. It also provides sample command-line options specific to the VxWorks simulator architecture. For more information on the available compiler options, see the compiler documentation for Pentium (Windows and Linux hosts) or SPARC (Solaris hosts).
Table 3-1 VxWorks Simulator Compiler Options
CPU Definition
Host (Run Type)
TOOL Variable Value
Compiler Command-Line Options

-tX86LH:vxworks65 -DCPU=SIMNT -mcpu=i486 -march=i486 -DCPU=SIMNT -mtune=i486 -march=i486 -DCPU=SIMNT -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer -tX86LH:vxworks65 -DCPU=SIMLINUX -mcpu=i486 -march=i486 -DCPU=SIMLINUX -mcpu=i486 -march=i486 -DCPU=SIMLINUX -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer
SIMNT
Windows (kernel)
diab gnu icc
64-bit Windows (kernel) gnu
icc
SIMLINUX
Linux (kernel)
diab gnu icc
64-bit Linux (kernel)
gnu
icc
19
Table 3-1
VxWorks Simulator Compiler Options (contd)
CPU Definition
Host (Run Type)
TOOL Variable Value
Compiler Command-Line Options

-tSPARCFH:vxworks65 -DCPU=SIMSPARCSOLARIS -DCPU=SIMSPARCSOLARIS -tSPARCFH:rtpsim -DCPU=SIMSPARCSOLARIS -mrtp -DCPU=SIMSPARCSOLARIS -tX86LH:rtpsim -DCPU=SIMPENTIUM -mcpu=i486 -march=i486 -DCPU=SIMPENTIUM -mcpu=i486 -march=i486 -DCPU=SIMPENTIUM -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer
SIMSPARCSOLARIS
Solaris (kernel)
diab gnu
Solaris (RTP)
diab gnu
SIMPENTIUM
Windows and Linux (RTP)
diab gnu icc
64-bit Windows and Linux (RTP)
gnu
icc
For example, to specify the CPU value for an application that will run in an RTP on a Windows (or Linux) host, use the following command-line option when you invoke the compiler:
-DCPU=SIMPENTIUM
On all hosts, the VxWorks simulator uses ELF object module format (OMF). Your VxWorks installation also includes a VxWorks simulator binary for each supported host system. You can use this binary as a boot loader for a VxWorks image that you can configure and build using exactly the same compiler options you use to build a VxWorks image for a hardware target architecture. Thus, if you are compiling a VxWorks image for a Linux or Windows VxWorks simulator, you should use the same compiler as the Intel Architecture. If you are compiling for the Solaris VxWorks simulator, you must compile for the SPARC architecture. If you attempt to load an ELF image for another architecture onto a VxWorks simulator, you will get a load error. For example, if you attempt to load a PPC32 ELF image from the kernel shell:
% ld < host:C:/WindRiver/workspace/PPC_ELF.out ld(): error loading file (errno = 0x610001). value = 0 = 0x0
For information on available compiler options, see the Wind River Compiler for x86 User's Guide or the Wind River Compiler for SPARC User's Guide.
3.3.2 Compiling Modules for Debugging

To compile C and C++ modules for debugging, you must use the -g flag to generate debug information. An example command-line sequence for the Wind River Diab Compiler is as follows:
% dcc -tX86LH:vxworks65 -DCPU=SIMNT -IinstallDir/target/h -g test.cpp
20
3 Introduction to the VxWorks Simulator Environment 3.4 Interface Variations
In this example, installDir is the location of your VxWorks tree and -DCPU specifies the CPU type. An equivalent example for the Wind River GNU Compiler is as follows:
% ccpentium -mcpu=i486 -march=i486 -DCPU=SIMNT -IinstallDir/target/h -g test.cpp
An equivalent example for the Intel C++ Compiler for VxWorks is as follows:
% icc -mtune=i486 -march=i486 -g -DCPU=SIMNT -IinstallDir/target/h test.c -o test.o
An equivalent example for the GNU compiler for 64-bit VxWorks is as follows:
% ccpentium -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-omit-frame-pointer-IinstallDir/target/h -g test.cpp
NOTE: Debugging code compiled with optimization is likely to produce
unexpected behavior, such as breakpoints that are never hit or an inability to set breakpoints at some locations. This is because the compiler may re-order instructions, expand loops, replace routines with in-line code, and perform other code modifications during optimization, making it difficult to correlate a given source line to a particular point in the object code. Users are advised to be aware of these possibilities when attempting to debug optimized code. Alternatively, users may choose to debug applications without using compiler optimization. To compile without optimization using the Wind River Diab Compiler, compile without the -XO option or use the -Xno-optimized-debug option. To compile without optimization using the GNU compiler, compile without a -O option or use the -O0 option.
3.4 Interface Variations

This section describes particular functions and tools that are specific to VxWorks simulator targets in any of the following ways:
available only for VxWorks simulator targets parameters specific to VxWorks simulator targets special restrictions on, or characteristics of, VxWorks simulator targets
For complete documentation, see the reference entries for the libraries, routines, and tools discussed in the following sections.
3.4.1 Memory Management Unit

This section describes the memory management unit implementation for the VxWorks simulator and how it varies from the standard VxWorks MMU implementation.
Simulation
The VxWorks simulator provides a simulated hardware memory management unit. The simulated MMU provides features comparable to those found on typical
21
hardware MMUs. The simulation uses features provided by the host operating system to map, unmap, and protect pages in memory. MMU simulation is provided for all supported host operating systems.
Translation Model
All VxWorks simulator implementations share a common programming model for mapping memory pages. The data structure sysPhysMemDesc[ ], defined in sysLib.c describes the physical memory address space. This data structure is made up of configuration constants for each page or group of pages. Use of the VM_STATE_CACHEABLE constant for each page, or group of pages, sets the cache to copy-back mode. In addition to VM_STATE_CACHEABLE, the following additional constants are supported:
VM_STATE_CACHEABLE_NOT VM_STATE_WRITEABLE VM_STATE_WRITEABLE_NOT VM_STATE_VALID VM_STATE_VALID_NOT
For more information on configuring virtual memory management, see the VxWorks Kernel Programmers Guide: Memory Management.
Page Size
The VxWorks simulator uses a page size that is determined by the memory page mapping routines in the host operating system. On Solaris and Linux-based simulators, this page size is 8 KB. On Windows simulators, this page size is 64 KB.
Limitations
The VxWorks simulator MMU implementation does not provide support for supervisor/user mode.
Running the VxWorks Simulator Without MMU Support
You can configure the VxWorks simulator to run without an MMU. For more information on how to configure your VxWorks image for this type of operation, see the VxWorks Kernel Programmer's Guide: Memory Management. To run the VxWorks simulator without an MMU, Wind River recommends that you change the MMU page size (VM_PAGE_SIZE parameter) in your VxWorks image to 0x1000 (the default value is 0x2000 on Solaris and Linux simulators and 0x10000 on Windows simulators) in order to limit the amount of physical memory required to run your applications.
22
3 Introduction to the VxWorks Simulator Environment 3.4 Interface Variations
3.4.2 RTP Considerations

Because the VxWorks simulator MMU implementation does not support supervisor/user mode, it is not possible to prevent a task running in an RTP from writing in the kernel memory space. Therefore, on the VxWorks simulator architecture, an RTP task can potentially crash a kernel task.
3.4.3 File System Support

This section discusses the file systems supported by the VxWorks simulator. For more information on file systems, see the VxWorks Kernel Programmers Guide.
Pass-Through File System (passFS)
By default, the VxWorks simulator uses a pass-through file system (passFS) to access files directly on the host system. For more information on using passFS with the VxWorks simulator, see 4.3.1 Pass-Through File System (passFS), p.37.
Virtual Disk Support
The VxWorks simulator provides virtual disk support which allows you to simulate a disk block device. The simulated disk block device can be used to access any file system supported by VxWorks. For more information on virtual disk support for the VxWorks simulator, see 4.3.2 Virtual Disk Support, p.38.
3.4.4 WDB Back End

The VxWorks simulator supports the WDB pipe and WDB RPC target agent communication back ends; the WDB pipe back end is used by default. If network support is enabled on your VxWorks simulator target, the WDB RPC back end can also be used.
3.4.5 Connection Timeout

Occasionally, VxWorks simulator sessions lose their target server connections when the host CPU becomes overwhelmed by too many requests. If you find that your application is frequently losing its target server connection, you can adjust the back end request timeout (-Bt) and back end request resend number (-Br) parameters from Workbench using the Advanced Target Server Options in your VxWorks Simulator Connection. For more information on resolving connection timeouts, see the Wind River Workbench By Example: Connecting to VxWorks Targets.
23
3.5 Architecture Considerations

This section describes characteristics of the VxWorks simulator architecture that you should be aware of as you write a VxWorks application. The following topics are addressed:
byte order hardware breakpoint floating-point support ISR stack protection interrupts memory layout
3.5.1 Byte Order

The Solaris simulator uses a big-endian environment. The Windows and Linux simulators use a little-endian environment.
3.5.2 Hardware Breakpoint

The VxWorks simulator does not support hardware breakpoints.
3.5.3 Floating-Point Support

For 32-bit VxWorks, Windows and Linux simulators use i387 floating-point registers and instructions. For 64-bit VxWorks, these simulators use SSE instructions. acos( ) cos( ) floor( ) pow( ) tan( ) asin( ) cosh( ) fmod( ) sin( ) tanh( ) atan( ) exp( ) log( ) sinh( ) atan2( ) fabs( ) log10( ) sqrt( )
The following floating-point routines are not available on the VxWorks simulator: cbrt( ) iround( ) trunc( ) iroundf( ) truncf( ) ciel( ) log2( ) cbrtf( ) log2f( ) infinity( ) round( ) infinityf( ) roundf( ) irint( ) sincos( ) irintf( ) sincosf( )
In addition, the following single-precision routines are not available: acosf( ) cielf( ) floorf( ) powf( ) tanf( ) asinf( ) cosf( ) fmodf( ) sinf( ) tanhf( ) atanf( ) expf( ) logf( ) sinhf( ) atan2f( ) fabsf( ) log10f( ) sqrtf( )
24
3 Introduction to the VxWorks Simulator Environment 3.5 Architecture Considerations
3.5.4 ISR Stack Protection

ISR stack overflow and underflow protection is supported on Solaris and Linux simulators. The VxWorks simulator does not require ISR stack overflow and underflow protection on Windows simulators because the Windows operating system automatically detects this type of error condition and handles it before VxWorks can take action. For more information on ISR stack protection, see the VxWorks Kernel Programmers Guide: Signals, ISRs, and Watchdog Timers.
3.5.5 Interrupts
This section discusses interrupt simulation on the VxWorks simulator and how interrupts are handled in the simulator environment.
Solaris and Linux Systems
On Solaris and Linux simulators, the hardware interrupt simulation is performed using host signals. For example, the VxWorks simulator uses the SIGALRM signal to simulate system clock interrupts. Furthermore, all host file descriptors (such as standard input) can be put in asynchronous mode, so that the SIGPOLL signal is sent to the VxWorks simulator when data becomes available. For more information on how to configure a host device to generate interrupts when data is available, see A. Accessing Host Resources. For the VxWorks simulator, signal handlers provide the equivalent functionality of interrupts available on other target architectures. You can install ISRs in the VxWorks simulator to handle these interrupts.
NOTE: Not all VxWorks routines can be called from ISRs. For more information,
see the VxWorks Kernel Programmer's Guide: Signals, ISRs, and Watchdog Timers. To run ISR code during a future system clock interrupt, use the watchdog timer facilities. To run ISR code during auxiliary clock interrupts, use the sysAuxClkxxx( ) routines. Table 3-2 shows how the Linux and Solaris simulator interrupt vector tables are assigned.
25
Table 3-2
Interrupt Assignments (Linux and Solaris Simulators)
Interrupt Vectors
Description
1 ... SIGUSR1 SIGUSR2 ... 32 33 ... 288
Host signal 1 User signal 1 User signal 2 Host signal 32 Interrupt vector for host file descriptor 1 (SIGPOLL) Interrupt vector for host file descriptor 256 (SIGPOLL)
You can create pseudo-drivers to use these interrupts. You must connect your interrupt code with the standard VxWorks intConnect( ) mechanism. For example, to install an ISR that logs a message whenever the host signal
SIGUSR2 arrives, execute the following commands:
On Solaris:
% intConnect (17, logMsg, "Help!\n")
On Linux:
$ intConnect (12, logMsg, "Help!\n")
Next, send the SIGUSR2 signal to the VxWorks simulator from the host. This can be done using the kill command. The ISR (logMsg( ) in this case) runs every time the signal is received.
NOTE: In your VxWorks applications, avoid using the preprocessor constants SIGUSR1 or SIGUSR2. VxWorks defines its own values for these constants and
those values differ from the host definitions. Therefore, you must specify the host signal numbers explicitly in your VxWorks application code. Only SIGUSR1 and SIGUSR2 can be used to represent user-defined interrupts (see Table 3-3).
Table 3-3 User-Defined Interrupts (Linux and Solaris Simulators)
Signal
Solaris Value
Linux Value
SIGUSR1 SIGUSR2
16 17
10 12
Windows Systems
On Windows the VxWorks simulator uses Windows messages to simulate hardware interrupts. For example, the VxWorks simulator uses messages to simulate interrupts from the network connections, the pipe back end, and so forth. For the VxWorks simulator, messages provide the equivalent functionality of interrupts available on other target architectures. You can install ISRs in the VxWorks simulator to handle these messages.
26
NOTE: Not all VxWorks routines can be called from ISRs. For more information,
see the VxWorks Kernel Programmer's Guide: Signals, ISRs, and Watchdog Timers. To run ISR code during a future system clock interrupt, use the watchdog timer facilities. To run ISR code during auxiliary clock interrupts, use the sysAuxClkxxx( ) routines. Table 3-4 shows how the Windows simulator interrupt vector table is assigned.
Table 3-4 Interrupt Assignments (Windows Simulators)
Interrupt Vectors
Description
0x0000 0x0001 0x0002 0x0003 0x0004 0x0005 0x0006-0x0009 0x0009-0x00ef 0x00f0-0x00ff 0x0100-0x017f 0x180-0x01ff 0x0200-0x02ff
system clock interrupt auxiliary clock interrupt timestamp rollover interrupt back end pipe interrupt SIO driver interrupt bus interrupt inter-processor interrupts (IPIs) reserved for internal use Wind River Media Library interrupt range ULIP interrupt range simulated network interrupt range user interrupt range
You can create pseudo-drivers to use these interrupts. You must connect your interrupt code using the standard VxWorks intConnect( ) mechanism. For example, the following code installs an ISR that logs a message whenever an auxiliary clock message arrives. In this example, the auxiliary clock rate is configured to generate two ticks per second using sysAuxClkRateSet( ) so that the message is logged every 500 ms.
% sysAuxClkRateSet (2) value = 0 = 0x0 % sysAuxClkEnable () value = 0 = 0x0 % intConnect (0x1, logMsg, "Aux Clock Int!\n")
The user interrupt range can be used by the host side user application. For more information on using user interrupts, see A. Accessing Host Resources.
27
3.5.6 Memory Layout

32-Bit Simulator
The VxWorks memory layout is the same for all 32-bit VxWorks simulators. Figure 3-1 shows the memory layout, labeled as follows:
Boot Line
ASCII string of boot parameters.

Exception Message
ASCII string of the fatal exception message.

System Image
The VxWorks system image itself (three sections: text, data, and bss). The entry point for VxWorks is at the start of this region.
Host Memory Pool
Memory allocated by the host tools. The size depends on the WDB_POOL_SIZE macro.
System Memory Pool
Size depends on the size of the system image. The sysMemTop( ) routine returns the top of VxWorks system RAM, not including user-reserved memory and persistent memory.
Interrupt Stack
Size is defined by ISR_STACK_SIZE under INCLUDE_KERNEL. The location depends on the system image size.
Interrupt Vector Table
Table of interrupt vectors.

User Reserved Memory
Application-reserved memory. Its size is configured through the USER_RESERVED_MEM parameter. By default, this memory region is cleared upon reboot; however, it can be changed using the CLEAR_USER_RESERVED_MEMORY_ON_COLD_BOOT parameter.
ED&R Persistent Memory
A reboot-safe protected memory region manager.

Shared Memory Address Space
Address space reserved for shared memory, which includes: the shared memory anchor the shared memory pool the address space for VxMP shared memory objects (if included) or the shared memory TIPC pool (if included) the DSHM pool (if included) the MIPC pool (if included) user shared memory (if included)
Networking Address Space
Address space for VxWorks simulator full networking (simnet), if network support is included.
28
Figure 3-1
32-Bit VxWorks System Memory Layout (VxWorks Simulator) LOCAL_MEM_LOCAL_ADRS
Boot Line (BOOT_LINE_SIZE) Exception Message
sysBootLine = BOOT_LINE_ADRS = LOCAL_MEM_LOCAL_ADRS+BOOT_LINE_OFFSET sysExcMsg = EXC_MSG_ADRS = LOCAL_MEM_LOCAL_ADRS+EXC_MSG_OFFSET
System Image text data bss
RAM_LOW_ADRS = LOCAL_MEM_LOCAL_ADRS+0x10000
_end Host Memory Pool (WDB_POOL_SIZE) _end + WDB_POOL_SIZE System Memory Pool Interrupt Stack (ISR_STACK_SIZE)
KEY Available Reserved
Interrupt Vector Table
intVecBaseGet( ) sysMemTop( )=LOCAL_MEM_LOCAL_ADRS+LOCAL_MEM_SIZE(USER_RESERVED_MEM+PM_RESERVED_MEM) sysMemTop( )=LOCAL_MEM_LOCAL_ADRS+ LOCAL_MEM_SIZE- PM_RESERVED_MEM SM_ANCHOR_ADRS= LOCAL_MEM_LOCAL_ADRS+LOCAL_MEM_SIZE
User Reserved Memory (USER_RESERVED_MEM) ED&R Persistent Memory (PM_RESERVED_MEM)
Shared Memory Address Space (SM_TOTAL_SIZE)
Networking Address Space (SIMNET_MEM_SIZE)
SIMNET_MEM_ADRS= SM_MEM_ADRS+SM_TOTAL_SIZE
SIMNET_MEM_ADRS + SIMNET_MEM_SIZE
29
64-Bit Simulator
Figure 3-2 shows the memory layout for the 64-bit VxWorks simulator on 64-bit Windows and Linux hosts.
Kernel Virtual Memory Pool Region
The kernel virtual memory pool region is the area used for dynamically managed mappings in the kernel.
Shared User Virtual Memory Region
This is the shared memory region that is used for creating the shared virtual memory pool. It is used to allocate code and data segments of shared libraries.
RTP Private Virtual Memory Region
This region is added to each RTPs page manager upon creation. It is used for allocating the RTPs code segments and private mappings.
Kernel System Virtual Memory Region
This region includes the following elements:
boot line exception message system image user reserved memory ED&R (error detection and recovery) persistent memory
30
Figure 3-2
Default Virtual Memory Layout for the 64-Bit VxWorks Simulator
Linux Host
0x1000.0000
Windows Host
Unused (~1.5 GB) 0x6000.0000 Unusable Unused (~4.5 GB) 0x1.4000.0000 =0x1.8000.0000 (LOCAL_MEM_LOCAL_ADRS) Kernel system virtual memory region (2 GB) 0x2.0000.0000 Unused (1 GB)
Kernel system virtual memory region (2 GB)
RTP Private Virtual Memory Region (configurable; default size is 4 GB) VXSIM_RTP_PRIV_RGN_BASE + VXSIM_RTP_RGN_SIZE
RTP Private Virtual Memory Region (configurable; default size is 4 GB)
Shared User Virtual Memory Region (configurable; default size is 4 GB) VXSIM_RTP_PRIV_RGN_BASE + VXSIM_RTP_RGN_SIZE + VXSIM_SHARED_RGN_SIZE
Shared User Virtual Memory Region (configurable; default size is 4 GB)
Kernel Virtual Memory Pool Region (configurable; default size is 4 GB) VXSIM_RTP_PRIV_RGN_BASE + VXSIM_RTP_RGN_SIZE + VXSIM_SHARED_RGN_SIZE + VXSIM_KERNEL_VIRT_RGN_SIZE Shared Memory Address Space (SM_TOTAL_SIZE) Networking Address Space (SM_TOTAL_SIZE)
Kernel Virtual Memory Pool Region (configurable; default size is 4 GB)
Shared Memory Address Space (SM_TOTAL_SIZE) Networking Address Space (SM_TOTAL_SIZE)
31
32
4
Using the VxWorks Simulator
4.1 Introduction 33 4.2 Configuring the VxWorks Simulator 33 4.3 Configuring Hardware Simulation 37 4.4 Using VxWorks SMP with the VxWorks Simulator 42 4.5 64-Bit VxWorks Simulation 44 4.6 Migrating Applications to a Hardware-Based System 45 4.7 Using a Telnet Client to Display the Simulator Console 45
4.1 Introduction
This chapter discusses how to use the VxWorks simulator for VxWorks development. It includes information on configuration, hardware simulation, and basic guidelines and limitations for migrating your application to a target hardware system.
4.2 Configuring the VxWorks Simulator

This section discusses configuration issues particular to the VxWorks simulator environment, including boot parameter configuration. For more information on general VxWorks configuration, see the VxWorks Kernel Programmers Guide: VxWorks Configuration.
4.2.1 Boot Parameters

Using the command-line interface, you can specify all parameters available in the standard VxWorks boot line for a VxWorks simulator target. However, you lose
33
these parameters when you exit the simulator even if you include non-volatile RAM support. This occurs because, even when the specified boot parameters are saved in a file (nvram.vxWorkscpuNum) similar to actual hardware target behavior, they are only used for a target reboot, not when the target is exited or restarted. Once the VxWorks simulator starts, you can use the VxWorks bootChange( ) routine to modify boot line parameters. The new parameters are preserved and taken into account on the next reboot.
NOTE: The bootChange( ) routine can be used to boot another VxWorks image.
However, the new image must be built with the same memory configuration. That is, the LOCAL_MEM_SIZE and LOCAL_MEM_LOCAL_ADRS macros in the BSP config.h file must be identical.
4.2.2 Memory Configuration

The VxWorks simulator displays its memory settings at startup, as shown in the following examples.
Example 4-1 32-Bit VxWorks Virtual Virtual Physical Physical Example 4-2 Base Top Base Top Address: Address: Address: Address: 0x10000000 0x50000000 0x10000000 0x12000000
Virtual
Size: 0x40000000 (1024Mb)
Physical Size: 0x02000000 (32Mb)
64-Bit VxWorks Virtual Base Address: 0x0000000180000000 Virtual Top Address: 0x0000000500000000 0x0000000380000000 (14Gb) Physical Base Address: 0x0000000180000000 Physical Top Address: 0x0000000188000000 0x0000000008000000 (128Mb)
Virtual
Size:
Physical Size:
The following sections discuss the VxWorks simulator memory parameters and describe how the parameters can be modified.
Physical Memory Address Space
The VxWorks simulator physical memory address space is defined by the LOCAL_MEM_LOCAL_ADRS and LOCAL_MEM_SIZE parameters in the VxWorks simulator BSP. The VxWorks simulator uses the values that were set for these parameters when you built VxWorks. However, the VxWorks simulator physical memory size can be dynamically modified using the VxWorks simulator command-line interface (using the -size or -memsize command-line options). Alternatively, you can do this in Workbench: in the Remote Systems view, right-click the simulator connection and select Properties; then use the Memory Options tab to set these options.
NOTE: The LOCAL_MEM_ADRS parameter must be aligned to 1 MB (0x100000) and the LOCAL_MEM_SIZE parameter must be a multiple of 1 MB.
34
4 Using the VxWorks Simulator 4.2 Configuring the VxWorks Simulator
NOTE: On the 32-bit VxWorks simulator, if you modify LOCAL_MEM_ADRS, you
may need to use the -vaddr command-line option to set a virtual address value that is coherent with the physical memory address space.
Virtual Memory Address Space (32-Bit VxWorks Simulator)
For the 32-bit VxWorks simulator, the virtual memory size is limited to 1 GB. On Windows hosts, the VxWorks simulator virtual base address is 0x10000000 and the VxWorks simulator virtual top address is 0x4FFFFFFF. On Solaris and Linux hosts, the VxWorks simulator virtual base address is 0x60000000 and the VxWorks simulator virtual top address is 0x9FFFFFFF.
NOTE: Depending on your host configuration, you may obtain less than 1 GB of
virtual memory. The default settings for the virtual memory base address and the virtual memory size should work for most host configurations. However, you may need to modify the virtual memory values in order to avoid a conflict between the VxWorks simulator address space and the host system DLL load addresses. You may also need to decrease the base address in order to get a larger address space. The default values for the virtual memory base address and the virtual memory size can be overridden using the -vaddr and -vsize command-line options. To do this in Workbench, go to the Remote Systems view, right-click the simulator connection and select Properties; then use the Memory Options tab to set these options.
NOTE: If you decide to modify the virtual memory base address or virtual memory size, you must ensure that the values are coherent with the physical memory address space.
Virtual Memory Address Space (64-Bit VxWorks Simulator)
For the 64-bit VxWorks simulator, the virtual memory size is 14 GB by default. You can modify this size through the VXSIM_KERNEL_VIRT_POOL_RGN_SIZE and VXSIM_SHARED_RGN_SIZE parameters, as shown in Figure 3-2. The virtual base address is 0x1.4000.0000.
User Shared Memory
In previous releases of VxWorks and the VxWorks simulator, the only memory shared among several instances of the simulator was restricted for the use of VxWorks components, such as MIPC or VxMP. As of this release of the VxWorks simulator, shared memory is available for your own implementations of inter-process communication.
35
Creating a User Shared Memory Area
To set up this kind of shared memory in your simulator instance, include the INCLUDE_VXSIM_USER_SM configuration component in your VxWorks image. This component is not included by default. In Workbench, it can be found in the Project Facility, in the simulator BSPs memory folder. The size of the user shared memory area is configurable. When you include the
INCLUDE_VXSIM_USER_SM component, use its VXSIM_USER_SM_SIZE
parameter to specify the size. The size value is rounded up to the MMU page size.
Multiple Simulator Instances
The user shared memory area can be shared by one or more VxWorks simulator instances. !
CAUTION: All VxWorks simulator instances that are connected to shared memory must have the same shared memory configuration, including for the user shared memory area. The size of the user shared memory area must be the same for all VxWorks simulator instances that use it. If you use different shared memory configurations for different instances, unpredictable results may occur.
Getting Information on the User Shared Memory Area
Once you have built the VxWorks simulator image and started it, you can view the current size and base address of the area through the sysUserSmInfoGet( ) routine. The synopsis for sysUserSmInfoGet( ) is as follows:
void sysUserSmInfoGet ( size_t * pSize, void ** pAddr )
/* where to return user shared memory size in bytes */ /* where to return user shared memory address */
If user shared memory is not configured in the system, this routine returns 0.
Using AMP Atomic Operators
You can manipulate the shared memory area through direct memory access (DMA) or with the AMP atomic operators (the vxTas( ) and atomic 32xxx( ) routines). Using SMP atomic operators (the vxAtomicxxx( ) routines) does not guarantee atomicity of the operation. For more information on VxWorks AMP atomic operators, see the VxWorks Kernel Programmers Guide: Atomic Operators for AMP.
Memory Protection Level
The VxWorks simulator allows you to specify a memory protection level using the -prot-level option. This level can be set to min, max, or an intermediate integer value representing a given protection level. By default, the memory protection is set to the maximum level (max).
NOTE: Currently, only one protection level is provided. See Table 4-1.
36
4 Using the VxWorks Simulator 4.3 Configuring Hardware Simulation
Table 4-1
Available Memory Protection Levels
Protection Level
Description
0 (min) 1 (max)
No specific protection Enable stack overflow protection
4.2.3 Miscellaneous Configuration

The VxWorks simulator command-line interface also provides a set of miscellaneous options for scripting, help, version, and so forth. For complete information on all available options, see the API reference entry for vxsim.
4.3 Configuring Hardware Simulation

This section discusses the available hardware simulation options for the VxWorks simulator.
4.3.1 Pass-Through File System (passFS)

The default file system for the VxWorks simulator is the pass-through file system (passFS). This file system is unique to the VxWorks simulator. The INCLUDE_PASSFS component is included by default and mounts this file system on startup. passFS is a file-oriented device driver that provides easy access to the host file system. To specify the passFS device name (the default is your system host name), use the following command-line option:
% vxsim -hn hostname
or
% vxsim -hostname hostname
On Linux and Solaris hosts, the default value for the passFS device name is the name of the host on which the simulator is running. On Windows, for backward compatibility with previous releases, the default value is host.
37
The VxWorks syntax for accessing a host file system is summarized in Table 4-2.
Table 4-2 VxWorks Syntax for Accessing passFS
Host Type
passFS Syntax
Example
Linux or Solaris Windows
passFSDevice:/dir/file passFSDevice:/disk/dir/file
ls myhost:/myDir/myFile (where host name is myHost) ls host:/c/myDir/myFile ls host:c:/myDir/myFile
passFSDevice:disk:/dir/file Windows (deprecated; syntax preserved for backward compatibility)
NOTE: passFS uses UNIX-style path separators (/) even on a Windows-based
simulator.
4.3.2 Virtual Disk Support

To simulate access to file systems, either the file system supplied with VxWorks or one you have implemented yourself, the VxWorks simulator includes support for virtual disks. A virtual disk converts all read and write accesses to read and write accesses to a file on the host file system. However, to an application running in a VxWorks image, accessing the virtual disk looks no different than any other disk in a VxWorks I/O system.
NOTE: Virtual disk support replaces the UNIX disk driver library (unixDrv)
included in earlier versions of the VxWorks simulator. By default, the VxWorks simulator includes support for virtual disks. The relevant configuration component is INCLUDE_VIRTUAL_DISK. To initialize the virtual disk system, call virtualDiskInit( ). After control returns from a successful call to virtualDiskInit( ), you can create a virtual disk instance by calling virtualDiskCreate( ):
BLK_DEV * vitualDiskCreate ( char * hostFile, int bytesPerBlk, int blksPerTrack, int nBlocks )
/* /* /* /*
name of the host file to use number of bytes per block number of blocks per track number of blocks on this device
*/ */ */ */
Although a successful call to virtualDiskCreate( ) creates a disk instance, there is not yet any name or file system associated with the instance. To create this association, you must call a file system device initialization routine. Consider the following code fragment:
BLK_DEV * vdBlkDev; vdBlkDev = virtualDiskCreate (hostFile, 512, 32, 32*200); fsmNameInstall("/Q:0", "/Q"); xbd = xbdBlkDevCreateSync(vdBlkDev, "/Q"); status = dosFsVolFormat("/Q", DOS_OPT_QUIET | DOS_OPT_BLANK, NULL);
38
This code creates /Q, a 3 MB DOS disk with 512-byte blocks, and 32 tracks. In support of this virtual disk, the virtualDiskCreate( ) call creates the file c:/tmp/filesys1 (if the file does not already exist). Do not delete this file while the virtual disk is open (to close a virtual disk, call the virtualDiskClose( ) routine). To check whether this code has successfully created a virtual disk, you can call devs( ), which should return the following:
drv 0 1 5 6 3 name /null /tyCo/0 host: /vio C:
4.3.3 Non-Volatile RAM Support

By default, a VxWorks image includes support for non-volatile RAM, which has a default size of 256 bytes. This memory is dedicated to storing boot line information. To store anything else in NVRAM, use the NV_RAM_SIZE macro to increase the size of NVRAM. To access NVRAM, use sysNvRamSet( ) and sysNvRamGet( ). To simulate NVRAM, the VxWorks simulator uses a file on the host system. By default, this file resides in the same directory that contains the VxWorks image. To specify another location, use the -nvram command-line option:
% vxsim -nvram pathToFileForNVRAM
4.3.4 Standard I/O

VxWorks simulator BSPs provide a standard I/O (SIO) driver to handle standard input and output. For Windows, Linux, and Solaris simulators, this driver is target/config/simpc/simSio.c.
NOTE: On Linux and Solaris simulators, UNIX job control characters are enabled even when the I/O is in raw mode. Trapping of control characters like ^Z is
UNIX-shell specific and does not conform to the usual VxWorks tyLib conventions. Trapping of the ^C character is performed by the kernel shell (when it is included in your image).
4.3.5 Timers
Similar to any VxWorks target, the VxWorks simulator provides a system clock and an auxiliary clock. The macros SYS_CLK_RATE_MIN, SYS_CLK_RATE_MAX, AUX_CLK_RATE_MIN, and AUX_CLK_RATE_MAX are defined to provide parameter checking for the sysClkRateSet( ) and sysAuxClkRateSet( ) routines.
NOTE: If the VxWorks simulator process is preempted by another process on the
host machine, the VxWorks simulator clock can be impacted. In such cases, the current activity of each VxWorks task is delayed by an interval of time that corresponds to the preempted time of the process.
39
4.3.6 Timestamp Driver

The VxWorks simulator provides a system-defined timestamp driver. In general, this driver is used to extend the range of information available from VxWorks kernel instrumentation. For example, when a timestamp driver is available, a precise time line can be displayed using the Wind River System Viewer. The timestamp driver is included in the default VxWorks simulator configuration. The timestamp driver is selected by including the INCLUDE_TIMESTAMP and INCLUDE_SYS_TIMESTAMP components in your VxWorks image.
NOTE: If the VxWorks simulator process is preempted by another process on the
host system, the System Viewer graph can be impacted. In this situation, the current activity of each VxWorks task is delayed by an interval of time that corresponds to the preempted time of the process.
4.3.7 Serial Line Support

The VxWorks simulator provides a sample host serial I/O driver (hostSio). This driver provides access to a host serial device from the VxWorks simulator. This feature is not included in the default VxWorks simulator. To add host serial device support, the INCLUDE_HOST_SIO component must be defined in the BSP configuration. The macro HOST_SIO_PORT_NUMBER can be used to select which host serial device to use. For more information, see A. Accessing Host Resources.
4.3.8 Shared Memory Network

You can configure a VxWorks system where multiple CPU boards are connected using a common backplane (for example, a VMEbus configuration). This allows the target boards to communicate through shared memory. VxWorks provides a standard network driver to access shared memory such that all higher-level network protocols are available over the backplane. In a typical configuration, one of the CPU boards (CPU 0) communicates with the host using Ethernet. The rest of the CPU boards communicate with each other, and the host, using the shared memory network. In this configuration, CPU 0 acts as a gateway to the outside network. This type of hardware configuration can be emulated using the VxWorks simulator. In this case, multiple VxWorks simulator instances are configured to use a host shared-memory region as the basis for the shared-memory network.
40
Figure 4-1
VxWorks Simulator Shared-Memory Network Shared Memory Network
161.27.0.1:ffffff00
161.27.0.2:ffffff00
161.27.0.3:ffffff00
Master (VxSim0) (CPU0)
Slave 1 (VxSim1) (CPU1)
Slave 2 (VxSim2) (CPU2)
192.168.200.1
vxsimnetd
Ethernet
Configuring Your VxWorks Simulator for a Shared-Memory Network
In order to configure the VxWorks simulator for use with a shared-memory network, you must configure your VxWorks image to use the following components:
INCLUDE_SM_NET INCLUDE_SM_COMMON INCLUDE_SM_OBJ
You can reconfigure your image using either the vxprj command-line utility or using the Workbench kernel configuration tool. For more information, see Wind River Workbench By Example: Configuring and Building VxWorks or the users guide for your Platform product.
Starting the Master Simulator
Use the master simulator to communicate with the host through the simnet device. You can specify the shared-memory network address for the master simulator by starting the VxWorks simulator instance with the -backplane (or -b) option as follows:
% vxsim -p 0 -d simnet -e 192.168.200.1 -b 161.27.0.1:ffffff00
NOTE: Because it is responsible for initializing the shared memory region, the
master simulator must always be started first. You must also reboot all slave instances each time the master instance is rebooted.
Starting the Slave Simulators
Once you start the master simulator instance, you can start slave simulator instances with a gateway set to the master simulator using the -gateway (or -g) option as follows:
% vxsim -p 1 -b 161.27.0.2:ffffff00 -g 161.27.0.1 % vxsim -p 2 -b 161.27.0.3:ffffff00 -g 161.27.0.1
An alternative option would be to start the slave simulator as follows:

% vxsim -p 1 -b 161.27.0.2:ffffff00
41
and then add a network route to specify which gateway should be used for communication. This is done from the VxWorks simulator kernel shell as follows:
-> routec "add -net 0.0.0.0/24 161.27.0.1"
NOTE: If you choose to use the alternative option described above, you must include the INCLUDE_ROUTECMD component in your VxWorks image. Configuring the Host System
Before your host system can communicate with the master simulator, you must configure your host routing table with the new subnet information. The routing information can be configured as follows: For Windows hosts, enter the following command from a Windows command shell:
C:\> route add 161.27.0.0 MASK 255.255.255.0 192.168.200.1
For Solaris and Linux hosts, enter the following command from your host shell:
# route add -net 161.27.0.0 192.168.200.1
NOTE: To configure routing information, you must have administrator or root
privileges on your host.
4.4 Using VxWorks SMP with the VxWorks Simulator

The VxWorks simulator provides support for the VxWorks SMP product. This allows you to test SMP applications before SMP hardware is available. A precompiled SMP image is located in installDir/vxworks-n.n/target/proj/vxsimBSP_smp/default. For example, on Windows hosts, the precompiled SMP image is installDir\vxworks-n.n\target\proj\simpc_diab_smp\default\vxWorks. The host OS simulates each CPU with a process that is scheduled by the host OS itself. Thus, SMP performance can be achieved when the host has more CPUs than the VxWorks simulator. Otherwise, since simulated CPUs have to share the real CPU power, performance will not match SMP expectations. You specify the number of simulated CPUs using the Workbench kernel configurator before building the VxWorks image. If you are using the VxWorks simulator to simulate multiple processors in SMP mode, you should be cautious when calling host routines from the VxWorks simulator. Review code that uses vxsimHostProcAddrGet( ) to make sure it is SMP-safe. Note that vxsimHostProcCall( ) replaces a direct function pointer dereference that is forbidden in SMP. For more detailed information see A.2 Accessing Host OS Routines, p.118. For general background on SMP, see the VxWorks Kernel Programmers Guide: VxWorks SMP.
NOTE: The VxWorks simulator also supports hardware simulation for the
VxWorks AMP product using MIPC. For more information on using VxWorks AMP with the simulator, see 7. Tutorial: Simulating VxWorks AMP.
42
4 Using the VxWorks Simulator 4.4 Using VxWorks SMP with the VxWorks Simulator
4.4.1 Creating an SMP Image

To create a new VxWorks simulator image that includes support for SMP, do the following: 1. Create a new VxWorks image project (VIP) in Workbench (for information, see the users guide for your Platform1). In the Options dialog of the wizard, check the SMP support in kernel option checkbox. If you want to change the number of processor cores (the default is two), use the Kernel Configuration facility. Go to operating system components > kernel components > kernel. Double-click on the line labeled Number of CPUs enabled (which corresponds to the parameter VX_SMP_NUM_CPUS). Change the highlighted number (2) to the desired number of CPUs. Build the project. Select Target > New Connection, then select the connection type Wind River VxWorks 6.x Simulator Connection. Click Next then click on Custom simulator and navigate to the project directory for the VIP you just built. Click Finish.
2.
3. 4. 5. 6.
When you connect to the SMP-enabled VxWorks simulator instance, the startup banner should indicate that VxWorks SMP is running. In addition, as shown in Figure 4-2, the startup sequence reports both the number of CPU cores that the VxWorks image expects and the actual number of CPU cores present on the host machine.
Figure 4-2 VxWorks Simulator SMP Startup Screen
1. The following steps assume that you are using the Workbench Advanced Device
Development perspective. The title bar at the upper left of the Workbench window shows the current perspective. To display the Advanced Device Development perspective, select Window > Open Perspective > Advanced Device Development.
43
At the VxWorks simulator prompt, you should be able to see the idle tasks running on the two different CPU cores by issuing the i command:
-> i NAME ---------tJobTask tExcTask tLogTask tNbioLog tShell0 tWdbTask tAioIoTask> tAioIoTask> tNet0 ipcom_sysl> tAioWait tIdleTask0 tIdleTask1 value = 0 = ENTRY -----------10098400 100976f0 logTask 10099240 shellTask wdbTask aioIoTask aioIoTask ipcomNetTask 1005bbb0 aioWaitTask idleTaskEntr idleTaskEntr 0x0 TID -------1042ac90 101d0e60 1042ebe8 1042f080 105c8648 104edee0 1044e2d0 1044e6f0 10466030 1046d950 1044adf8 103a9778 103e4000 PRI --0 0 0 0 1 3 50 50 50 50 51 287 287 STATUS ---------PEND PEND PEND PEND READY PEND PEND PEND PEND PEND PEND READY READY PC -------101349d6 101349d6 10132ad5 101349d6 1013e390 101349d6 101350e1 101350e1 10134742 101350e1 101349d6 100366f6 100366f6 SP ERRNO CPU # -------- ------- ----1066ff48 0 101d0d50 0 106afed8 0 106efef8 0 108be058 0 0 1086fee8 0 1076fd28 0 107afd28 0 107eff54 0 1060fe58 0 1072feb8 0 103a9600 0 103e3e88 0 1
4.5 64-Bit VxWorks Simulation

The VxWorks simulator now supports development of applications for operation in 64-bit mode. The 64-bit VxWorks simulator works the same way as the simulator for 32-bit VxWorks, with very few exceptions. You start the simulator in the same way, build applications, and include networking in the same way.
Limitations
The 64-bit VxWorks simulator is supported on 64-bit Windows and Linux hosts only.
4.5.1 Creating a 64-Bit Image

To build a 64-bit image for the VxWorks simulator, you follow the same process you would use to build a regular 64-bit VxWorks image (based on the simpc or linux simulator BSP), except that for 64-bit simulation, the VxWorks simulator has the following kernel configuration parameters for specifying virtual address space:
VXSIM_RTP_PRIVATE_RGN_SIZE
Defines the size of the RTP user virtual memory region. The RTP virtual address will be between 0x2 0000 0000 and (0x200000000 + VXSIM_RTP_PRIVATE_RGN_SIZE).
VXSIM_SHARED_RGN_SIZE
Defines the size of the user shared virtual memory region (shared library addresses).
VXSIM_KERNEL_VIRT_POOL_RGN_SIZE
Defines the size of the kernel virtual pool.
44
4 Using the VxWorks Simulator 4.6 Migrating Applications to a Hardware-Based System
4.5.2 Large Code Model

For the 64-bit VxWorks simulator, only the X86-64 ABIs large code model is supported for RTP executables and user-mode libraries. This is in contrast to the standard 64-bit VxWorks operating system, for which only the small code model is supported for RTP executables and user-mode libraries. (The medium code model is not supported in either case.)
4.6 Migrating Applications to a Hardware-Based System

Kernel and RTP applications developed using the VxWorks simulator are easily transferred to target hardware systems. However, because the VxWorks simulator environment is not a suitable basis for developing hardware device drivers, more work may be required once your application is transferred to the target system. To migrate your application, change your project build specifications to reflect the new hardware-based system. This involves recompiling your code using the appropriate CPU type for your target hardware. For more information on building applications for your target architecture, see the VxWorks Architecture Supplement. For general application build instructions, see the Wind River Workbench By Example: Configuring and Building VxWorks.
4.7 Using a Telnet Client to Display the Simulator Console

To access the VxWorks simulator console through a Telnet client: 1. Launch an instance of the simulator and a Telnet server for displaying its console. To do this you use the -add_dev option of the vxsim command. The syntax of the option is: -add_dev serial0=telnet:[portNumber]:[nowait],[nokill] where the optional parameters are interpreted as follows: The optional parameters are interpreted as follows:
portNumber the port to use; if omitted, the VxWorks simulator chooses the port number. nowaitThe simulator starts without waiting for the client to connect. nokillAllows the console to be closed and restarted without killing the simulator process.
45
Examples: vxsim -add_dev serial0=telnet vxsim -add_dev serial0=telnet:5656:nowait vxsim -add_dev serial0=telnet::nowait Note the double colon (::) in the last example. It is required when no port number is specified and causes the VxWorks simulator to supply a port number. 2. If you did not specify a port number for the Telnet server with the add_dev option, use the -list_dev option of the vxsim command to obtain the port number. The -list_dev option has the following forms: -list_dev serial0 -list_dev all In the current release, both forms of the option are equivalent, because only a serial device used for displaying the console over Telnet is supported. On UNIX, the -list dev option displays the port number on the standard output. On Windows, the VxWorks simulator is not a console application, and simulator output is not displayed on the standard output. To obtain the port number, you need to use -list_dev with the -l option. This writes the port number to the log file specified with -l. In the current release, output from -list dev appears as follows: serial0=telnet:portNumber 3. Connect a Telnet client to the Telnet Server: telnet localhost portNumber The preceding steps display the VxWorks simulator console in a new window. You can also display the console directly in Workbench. For more information, see 2.4.3 Launching the VxWorks Simulator from Workbench, p.14.
Disconnecting the Simulator
To exit the simulator, do one of the following:
On Windows:
reboot(1)
On UNIX:
CTRL+\ or
reboot(1)
46
5
Networking with the VxWorks Simulator
5.1 Introduction 47 5.2 Full Network Simulation: simnet 48 5.3 Network Redirection: simnet_nat 71
5.1 Introduction
Starting with Wind River VxWorks Simulator 6.9, two types of networking are available for the VxWorks simulator: network redirection (also known as network address translation, or NAT), which is provided through the simnet_nat boot device; and full network simulation, provided in the simnet device. simnet_nat provides a simple solution that is limited to UDP/TCP protocols, while simnet allows more complex network simulation. The main differences between these two networking methods are summarized in Table 5-1.
Table 5-1 Networking Methods for the VxWorks Simulator
Networking Method
Description
Limitations
simnet
Allows various protocol and subnet configurations. Uses the vxsimnetd daemon. Allows access to network resources, including the Internet. Does not require the installation of any driver on the host. Does not require the use of vxsimnetd. Does not require specification of a gateway or target IP address.
You must start vxsimnetd before starting a simulator instance. Acts as a firewall by default, and as such does not permit any incoming traffic. Does not support protocols other than TCP and UDP. Therefore, it does not support ping and other ICMP utilities.
simnet_nat
Full network simulation, through the simnet device, is described in detail in 5.2 Full Network Simulation: simnet, p.48.
47
Network redirection, through the simnet_nat device, is described in detail in 5.3 Network Redirection: simnet_nat, p.71.
5.2 Full Network Simulation: simnet

The VxWorks simulator provides support for setting up a subnetor multiple subnetsusing a network of VxWorks simulator instances. This chapter discusses how to configure your system and the required VxWorks simulator instances for use in a simulated subnet or subnets. It includes general network simulation information, instructions for setting up the VxWorks simulator network daemon (vxsimnetd) and installing the host connection driver, and information on configuring your simulated network. It also includes information on the wrnetdlink tool that allows you to set up a simulated subnet over multiple host systems. Tutorials for setting up various types of simulated networks are provided in 6. Networking Tutorials.
NOTE: The VxWorks simulator supports IPv6. For IPv6 configuration information, see the Wind River Network Stack Programmer's Guide, Volume 1: Transport and Network Protocols: Configuring Transport and Network Protocols. For information on using the VxWorks simulator with IPv6, see 6.6 IPv6 Tutorial, p.97.
5.2.1 Building Network Simulations

Using the VxWorks simulator network daemon, you can link same-host VxWorks simulator instances into simulated subnets. By default, these internal subnets do not communicate with the host. However, included with the VxWorks simulator is a simulated network drivea host adapter interfacethat you can use to give the host system an address on the simulated subnet.
NOTE: You can also use the wrnetdlink tool to create and link simulated subnets across multiple host systems. For more information, see 5.2.5 Configuring a Subnet Across Multiple Hosts Using wrnetdlink, p.69.
Through the host adapter, packet sniffers, such as tcpdump, snoop, or ethereal, can monitor traffic on an internally simulated subnet. In addition, this adapter on the simulated subnet lets you use the host to route packets for the subnet and thus link it with an external network. Figure 5-1 shows two subnets, 192.168.3.0 and 192.168.2.0, simulated on a single host.
48
5 Networking with the VxWorks Simulator 5.2 Full Network Simulation: simnet
Figure 5-1
VxWorks Simulator Instances on Simulated Subnets Host Adapter Interface 192.168.200.254 VxSIM Network Daemon 192.168.3.1
External Network Workstation
Hosts IP Address
VxSIM 1
192.168.200.3
192.168.200.4
VxSIM 3 Virtual Network 192.168.200.0
VxSIM 4
192.168.3.2
VxSIM 2
Virtual Network 192.168.3.0
Virtual subnet 192.168.3.0 is an entirely internal subnet. It is isolated from the host, although you can use a kernel shell or the target server (using the WDB pipe back end) to access a target. After you have access to one target on the subnet, you can use the subnet to communicate with other targets on the subnet. Virtual subnet 192.168.200.0 is an external subnet. It is networked to the host workstation through the host adapter interface, 192.168.200.254. If you set up the host system route table correctly, the host system can route packets for the 192.168.200.0 subnet. As shown in Figure 5-2, it is possible to create a multiple interface VxWorks simulator instance. Using such a VxWorks simulator instance, it is possible to route between simulated subnets.
49
Figure 5-2
VxWorks Simulator Instances Can Support Multiple Network Interfaces
External Network Workstation
Hosts IP Address
Host Adapter Interface
192.168.200.254 VxSIM Network Daemon 192.168.3.1
VxSIM 1
192.168.200.3 192.168.3.3
192.168.200.4
VxSIM 3 Virtual Network 192.168.200.0
VxSIM 4
192.168.3.2
VxSIM 2
Virtual Network 192.168.3.0
In Figure 5-2, the multi-interface VxSIM 3 can route packets from the 192.168.3.0 subnet to the greater external network through the host adapter to the host, which can then route packets to the external network through its network interface.
5.2.2 Setting Up the Network Daemon

The VxWorks simulator includes a network daemon that you can use to link multiple VxWorks simulator instances into one or more subnets. You can also use this network daemon to link these subnets (or even individual VxWorks simulator instances) to the larger Internet. The network daemon can support any protocol over the Ethernet layer (for example, TCP/IP). Thus, you can use the VxWorks simulator instances to test any broadcasting or multicasting features you may have built into an application. If you want to set up an externally visible subnet (able to communicate with or through the host), you must install the VxWorks simulator host connection driver (TAP driver) before configuring and starting the VxWorks simulator network daemon (see 5.2.3 Installing the Host Connection Driver, p.63).
NOTE: Although the VxWorks simulator network daemon allows you to set up
complex simulated networks, it is also required for minimal networksthat is, a connection between the host and a single simulator instance. The VxWorks simulator network daemon can be started either as a service (Windows service or root service on Linux and Solaris), which is the recommended method, or from the command line. The following sections describe how to set up a VxWorks simulator network daemon. For more information on the VxWorks simulator host connection driver, see 5.2.3 Installing the Host Connection Driver, p.63.
50
NOTE: If you want to use a VxWorks simulator instance(s) on a simulated
network, you must start the VxWorks simulator network daemon before you start the VxWorks simulator instance. Keep in mind that even a connection between the host system and a single instance requires the network daemon.
Starting the Network Daemon as a Service
Wind River recommends starting vxsimnetd as a Windows service (or a root service on Linux and Solaris) because this method provides full network support for the VxWorks simulator even if you are not logged in with administrator or root privileges on the host system.
NOTE: You must remove any previously installed network daemon services
before attempting to install a new service. For example, if you installed a network daemon service (vxsimnetds) as part of an earlier VxWorks simulator release, you must remove the old service before attempting to install a service from the latest release. (This may be the case even if you removed your previous installation using a Wind River uninstallation utility.) For information on removing the network daemon service, see Removing the Network Daemon Service, p.57.
Windows Hosts
On Windows hosts, you can install and configure the network daemon service from the VxWorks Development Shell (recommended) or from the Windows command shell (Start > Run... > cmd).
NOTE: The vxsimnetds_inst.exe program is a command-line installer for the vxsimnetd service. Run it just once, to install the service, or again to modify the parameters of the service.
To run vxsimnetd directly from the command line (that is, not as a service), use vxsimnetd.exe.
VxWorks Development Shell
To install from the VxWorks Development Shell, do the following: 1. Open the VxWorks Development Shell by selecting Start > Wind River > VxWorks N.N and General Purpose Technologies > VxWorks Development Shell. If you have an existing vxsimnetd service from a previous VxWorks simulator installation, you must remove the service. To remove it, execute the following command from the VxWorks Development Shell:
-> vxsimnetds_inst.exe /u
2.
3.
Install the new network daemon. From the VxWorks Development Shell, run the following command:
-> vxsimnetds_inst.exe
51
Windows Command Shell
To install from the Windows command shell, do the following:

NOTE: You must run vxsimnetds_inst.exe with administrator privileges.
In addition, if User Access Control is set to on, you must use Run as Administrator. To do so, right-click the executable file, and select Run as Administrator. The basic instructions for installing the service are as follows: 1. 2. Log in to the Windows host with administrator privileges. If you have an existing vxsimnetd service from a previous VxWorks simulator installation, you must remove the service. To remove it, select Run... from the Windows Start menu and execute the following command:
C:\> installDir/vxworks-6.x/host/x86-win32or64/bin/vxsimnetds_inst.exe /u
where installDir is the name of your VxWorks installation directory. 3. Install the new network daemon. From the Windows Start menu, select Run.... Browse to installDir/vxworks-6.x/host/x86-win32or64/bin/vxsimnetds_inst.exe (where installDir is the name of your VxWorks installation directory) and click OK to run the file.
Configuring the Network Daemon Service
As described above, the basic command-line execution required to install the network daemon service is as follows:
-> vxsimnetds_inst.exe
or
C:\> installDir/vxworks-6.x/host/x86-win32or64/bin/vxsimnetd_inst.exe
However, the following configuration options are available: /p The preserve option (/p) allows you to keep a previous network daemon service (vxsimnetds) configuration. When used, this option loads the saved configuration parameters from the previously installed network daemon service (parameters are saved when a service is removed). If the /p option is omitted, default parameters are used. /d The /d option specifies the directory to which the vxsimnetds files are copied. This option is mandatory if you are installing on a mounted drive. Note that this option requires that you specify an existing directory; the directory cannot be created at runtime. /u The /u option stops and uninstalls the current vxsimnetds service. When the service is removed, the configuration parameters are saved and can be reused for the next installation by specifying the /p option. (For more information, see Removing the Network Daemon Service, p.57.)
52
/get parameter This option allows you to display the following network daemon service parameters: CONFIG_FILE, SHELL_SERVER, SHELL_SERVER_PORT, LOGGING_LEVEL, and LOG_FILE. Specifying this option without any parameters displays values for all parameters in the following form:
Subnet Configuration File: file Shell Server: Enabled Shell Server Port Number: 7777 Logging Level: 1 Log File: file
/set parameter This option allows you to set the following network daemon service parameters: ConfigFile, ShellServer, ShellPort, LogLevel, and LogFile. Parameters can be set as follows:
C:\> vxsimnetds_inst /set ConfigFile=file /set ShellServer=[yes|no] /set ShellPort=value /set LogLevel=value /set LogFile=logFile
Starting the Network Daemon Service
To start the service: 1. 2. 3. Open Control Panel > Administrative Tools. Click Services. Select Wind River Network Daemon for VxWorks Simulator and start the service by right-clicking and selecting Start. (If the service is set to Disabled, right-click Wind River Network Daemon for VxWorks Simulator, select Properties, and set the startup type to Automatic. You can then start the service by right-clicking and selecting Start.)
By default, the network daemon starts with the default 192.168.200.0 external subnet configuration and with a shell server (-sv option). To change these options, right-click Wind River Network Daemon for VxWorks Simulator, select Properties, and specify the desired options before starting the service. Once the network daemon service is started, non-administrator users can start VxWorks simulator instances and attach them to any configured subnet.
Solaris and Linux Hosts
On Solaris and Linux hosts, vxsimnetd can be run as a root service. To do this, create scripts for Solaris and Linux systems that start vxsimnetd automatically on reboot (use the -sv option if you want the ability to modify network configuration).
NOTE: The following steps must be executed with root privileges.
You can install vxsimnetd as a root service using the following steps: 1. Copy vxsimnetd to your /usr/sbin directory. For Linux hosts, vxsimnetd is located in installDir/vxworks-6.x/host/x86-linux2/bin/. For Solaris hosts, vxsimnetd is located in installDir/vxworks-6.x/host/sun4-solaris2/bin/.
53
2.
Create a vxsimnetd script as follows in /etc/init.d: On Solaris, use the following script:
#!/bin/sh # # description: Starts and stops the vxsimnetd daemon # used to provide external network access to the # VxWorks simulator. case "$1" in start) if [ -x /usr/sbin/vxsimnetd ] ; then echo "Starting vxsimnetd ..." /usr/sbin/vxsimnetd -sv fi ;; stop) echo "Stopping vxsimnetd ..." /usr/bin/pkill -x vxsimnetd ;; *) echo "Usage: $0 {start|stop}" exit 1 esac exit 0
On Linux, use the following script:

#!/bin/sh # # chkconfig: 3 91 02 # description: Starts and stops the vxsimnetd daemon \ # used to provide VxWorks Simulator network services. # # pidfile: /var/run/vxsimnetd.pid
# Source function library. if [ -f /etc/init.d/functions ] ; then . /etc/init.d/functions elif [ -f /etc/rc.d/init.d/functions ] ; then . /etc/rc.d/init.d/functions else exit 0 fi # Check that vxsimnetd exists. [ -x /usr/sbin/vxsimnetd ] || exit 0
RETVAL=0
start() { echo -n $"Starting vxsimnetd service: " daemon vxsimnetd -sv RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/vxsimnetd || \ RETVAL=1 return $RETVAL } stop() { echo -n $"Shutting down vxsimnetd services: " killproc vxsimnetd RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/vxsimnetd echo ""
54
return $RETVAL } restart() { stop start } rhstatus() { status vxsimnetd } case "$1" in start) start ;; stop) stop ;; restart) restart ;; status) rhstatus ;; condrestart) [ -f /var/lock/subsys/vxsimnetd ] && restart || : ;; *) echo $"Usage: $0 {start|stop|restart|status|condrestart}" exit 1 esac exit $?
3.
Create a link. On Solaris, create a link in /etc/rc3.d/ as follows:

# ln -s /etc/init.d/vxsimnetd S91vxsimnetd
On Linux, in /etc/init.d/, run:

$ /sbin/chkconfig --add vxsimnetd
This creates two links on /etc/init.d/vxsimnetd, /etc/rc3.d/S91vxsimnetd and /etc/r6.d/K02vxsimnetd. 4. Start vxsimnetd as follows:
# /etc/init.d/vxsimnetd start
or reboot your host.
Starting the Network Daemon from the Command Line
You can use the vxsimnetd command to start the VxWorks simulator network daemon on your host system. You can configure the daemon using a configuration file statically at startup time or you can configure it interactively using the daemons debug shell. You can also combine these configuration methods, which allows you to use a configuration file to supply some defaults and read in additional configuration files as needed.
55
NOTE: If the daemon must support an externally visible subnet, you must launch the daemon from a task with the appropriate privileges. On a Solaris or Linux host, this means starting the daemon with supervisor or root privileges. On a Windows host, this means starting the daemon with administrator privileges.
In addition, on Windows hosts, if User Access Control is set to on, you must use Run as Administrator. To do so, right-click the executable file, and select Run as Administrator. The vxsimnetd command supports the following options: -f or -file This option specifies the configuration file that is parsed when the network daemon starts. For more information on the format of this file, see Creating a Network Daemon Configuration File, p.59. -s or -shell This option starts a debug shell that you can use to control network daemon configuration interactively. For more information on the debug shell options, see Network Daemon Debug Shell, p.57. -sv or -shellserver This option starts the network daemon in server/background mode. When in background mode, you can telnet to a debug port to access the debug shell. The -sv and -s options are mutually exclusive. -sp or -shellport This option specifies the debug port used to start a shell on a network daemon in background mode. If not specified, the default port is 7777. -force Forces the deletion of IPC objects left after vxsimnetd dies (UNIX only). To configure the daemon statically, use a command such as the following, where vxsimnetd.conf is a file supplying configuration parameters:
% vxsimnetd -f vxsimnetd.conf
To start the VxWorks simulator network daemon interactively, use a command such as the following, where vxsimnetd.conf is a file supplying configuration parameters:
% vxsimnetd -f vxsimnetd.conf -s
If you use the -sv option instead of the -s option, the debug shell runs in the background and is accessible using telnet. For example:
% telnet hostname portNumber
The portNumber defaults to 7777, but vxsimnetd supports the -sp parameter, which you can use to specify a different port number. vxsimnetd can also be started without any configuration options. In this case, the network daemon is started with a default external subnet of 192.168.200.0 and with the host node set in promiscuous mode.
56
Removing the Network Daemon Service NOTE: The product uninstaller does not uninstall vxsimnetd. If you plan to
uninstall the product, be sure to uninstall vxsimnetd (as described above) before running the uninstaller program. To remove the network daemon service (vxsimnetd), open a VxWorks Development Shell and enter the following:
-> vxsimnetds_inst.exe /u
This removes the vxsimnetd service.
Network Daemon Debug Shell
You can access the network daemon debug shell by starting vxsimnetd with the -s (or -shell) or -sv (or -shellserver) option. The shell supports command-line completion as well as history with two editing modes, emacs (default) or vi. The available shell commands are: subnet [subnetName] This command displays subnet information. When no subnet is specified, the command lists a summary for all configured subnets. A detailed summary is provided when a subnet name is specified. node subnetName [nodeIp] node subnetName [nodeNb] This command displays information about how many nodes are configured and used. For example:
vxsimnetd> node default NODE INFORMATION: CONFIGURED IN-USE 33 1
MAX 1
TOTAL 1
FAIL 0
Current Nodes of the subnet (default): # COMM STATUS IP PROMISC RCVQ PID 0 special(*) UP 192.168.200.254 Yes 0 24076
If you specify a node number (nodeNb) or node IP address (nodeIp), the node command displays specifics about the particular node, such as the number of packets sent and received. For example:
vxsimnetd> node default 0 # COMM STATUS IP PROMISC RCVQ PID 0 special(*) UP 192.168.200.254 Yes 0 24076 MAC ADDRESS: Mac Address SEND/RECEIVE # of # of # of STATISTICS: receives sends send failures
7a:7a:c0:a8:c8:fe
0 6 6
RECEIVE QUEUE INFORMATION: CONFIGURED CURRENT 64 0
MAX 0
57
packet subnetName This command displays packet information for a subnet. For example:
vxsimnetd> packet default PACKET INFORMATION: CONFIGURED IN-USE 100 1
MAX 1
TOTAL 7
FAIL 0
HANGING PACKETS: PKT-# SEND-NODE RECV-NODE 0 192.168.200.254[E] N/A
LEN 1514
REFCNT 0
PKTPTR 0xff0e2b14
In this example, the default subnet is configured with 100 packets, only one is currently in use, and seven packets were used in total. The hanging packets section displays packets that are allocated but not yet sent. help [command] This command specifies detailed help for a given command. If no command is specified, a summary of all available commands is provided.
?
Displays a one-line summary for all commands. quit This command exits the shell. If you started vxsimnetd with the -s option, this command destroys all subnets and vxsimnetd exits. For more information on vxsimnetd options, see 5.2.2 Setting Up the Network Daemon, p.50. source configFile This command reads subnet configuration information from a file and adds the corresponding subnets. If vxsimnetd cannot add all configured subnets, then this command adds no subnets at all. delete subnetName This command deletes a configured subnet. To delete all subnets, use delete all. extpromisc subnetName 0 extpromisc subnetName 1 This command sets the promiscuous mode for the host node of an external subnet. The 0 option sets promiscuous mode to off, 1 sets promiscuous mode to on. When the external node is in promiscuous mode (1), it receives every packet sent on the subnet. While this heavily impacts network performance, it allows you to analyze network traffic by connecting a packet sniffer on the external host node interface. errorrate subnetName This command sets the error rate for a given subnet. The error rate is the percentage of packets that will not be sent without giving error notification to the sender. Thus, if the error rate is set at five percent, five randomly chosen packets per 100 will be purposely lost. This feature is provided to simulate packet loss on an actual subnet. timeout subnetName This command sets the subnet timeout value. If a node does not read any packets for the length of time specified as the timeout, the packets are picked up by garbage collection. mode vi mode emacs This command sets the shell editing mode to vi or emacs.
58
Creating a Network Daemon Configuration File
A network daemon configuration file specifies values for the vxsimnetd configuration parameters. To specify a configuration file, use the -f option with the vxsimnetd command (the command used to start the network daemon). In your configuration file, to assign a value to a parameter, enter a semicolon-terminated ( ; ) line with the following format, where PARAMETER is either a parameter name in capital letters or an alias:
PARAMETER = value;
For parameters related to a subnet, group those parameters using the following syntax:
SUBNET_START subnetName { SUBNET_PARAM = value; };
For example, consider the following default configuration file:

SUBNET_START default { SUBNET_EXTERNAL = yes; SUBNET_EXTPROMISC = yes; SUBNET_ADDRESS = "192.168.200.0"; };
This configures the VxWorks simulator network daemon to support a subnet with external access. The network address for the subnet is 192.168.200.0 and, because the network mask is not specified, the pre-CIDR1 default mask applies. For 192.168.200.0, that would be the mask for a class C address, which is 0xffffff00. To add another subnet, you could add the following lines:
SUBNET_START user1 { SUBNET_UID = 323; SUBNET_GID = 100; SUBNET_ACCESSMODE = "0600"; SUBNET_ADDRESS = "192.168.201.0"; };
NOTE: While you can use a configuration file to overwrite the default values for
these parameters, if you add the configuration file dynamically, through the vxsimnetd shell, the default values are not modified. For example, if vxsimnetd is started with a configuration in which
DEFAULT_MAC_PREFIX is set to 7a7b, every subsequent dynamically added
subnet will use this value. To add a subnet with a different value, you must add it through a configuration file that redefines the value of DEFAULT_MAC_PREFIX. The parameters supported in a VxWorks simulator network daemon configuration file are described in Table 5-2.
1. CIDR refers to classless inter-domain routing. See RFCs 1518 and 1519.
59
Table 5-2
VxWorks Simulator Network Daemon Configuration Parameters
Parameter Default Parameters:
Description
DEFAULT_GARBAGE
Alias: dgarbage Default Value: 30 Specifies the number of seconds in the garbage collection interval. For each subnet, the garbage collection thread runs every DEFAULT_GARBAGE seconds. Garbage collection removes any dead nodes from the configured subnets.
DEFAULT_MACPREFIX
Alias: dmacprefix Default Value: 7a:7a Specifies the first bytes of simulator Ethernet addresses.
DEFAULT_UID
Alias: duid Default Value: user ID of the user that started the network daemon Defines the user ID (UNIX only).
DEFAULT_GID
Alias: dgid Default Value: group ID of the user that started the network daemon Defines the group ID (UNIX only).
DEFAULT_ACCESSMODE
Alias: daccessmode Default Value: "0666" Defines access mode (UNIX only). You can use the three parameters (duid, dgid, and daccessmode) to restrict access to subnets to a given user or group of users when the network daemon is shared between users on the same host.
DEFAULT_EXTERNAL
Alias: dexternal Default Value: no Defines the default subnet type.
DEFAULT_EXTPROMISC
Alias: dextpromisc Default Value: yes Defines whether the external subnet host node is set in promiscuous mode.
DEFAULT_ERRORRATE
Alias: derrorate Default Value: 0 Defines the default subnet error rate.
60
Table 5-2
VxWorks Simulator Network Daemon Configuration Parameters (contd)
Parameter
Description
DEFAULT_TIMEOUT
Alias: dtimeout Default Value: -1 Defines how long packets queued to a VxWorks simulator instance are left in the queue. The default is forever.
Subnet-Specific Default-Override Parameters:
SUBNET_MACPREFIX
Alias: macprefix Default: DEFAULT_MACPREFIX Specifies the first two bytes of the Ethernet address on this subnet. Overrides DEFAULT_MACPREFIX.
SUBNET_UID
Alias: uid Default: DEFAULT_UID Specifies the user IP for this subnet. Overrides DEFAULT_UID.
SUBNET_GID
Alias: gid Default: DEFAULT_GID Specifies the group ID for this subnet. Overrides DEFAULT_GID.
SUBNET_ACCESSMODE
Alias: accessmode Default: DEFAULT_ACCESSMODE Specifies the access mode for this subnet. Overrides DEFAULT_ACCESSMODE.
Topology Parameters:
SUBNET_ADDRESS
Alias: address Default: "0.0.0.0" Specifies the network address for this subnet.
SUBNET_MASK
Alias: mask Default: Pre-CIDR mask associated with the address in SUBNET_ADDRESS. Specifies the subnet mask for this subnet.
SUBNET_EXTERNAL
Alias: external Default: DEFAULT_EXTERNAL Specifies whether this subnet can communicate with the host on which it runs. This communication requires you to create a VxWorks simulator target with a network interface on the host systems network, and to start the VxWorks simulator network daemon with administrator privileges.
61
Table 5-2
Parameter
Description
SUBNET_EXTPROMISC
Alias: extpromisc Default: DEFAULT_EXTPROMISC Specifies whether the host sees every packet sent on this subnet. It allows you to attach a sniffer on the host interface to monitor traffic. However, it has a dramatically negative impact on network performance.
SUBNET_EXTDEVNUM
Alias: extdevice Default: 0 Specifies the host device number to use. This parameter is required when using more than one external subnet.
Resource-Related Parameters:
SUBNET_MAXBUFFERS
Alias: maxbuffers Default: 100 Specifies the maximum number of packet buffers available.
SUBNET_MAXNODES
Alias: maxnodes Default: 32 Specifies the maximum number of simulators that can attach to this subnet.
SUBNET_RECQLEN
Alias: recvqlen Default: 64 Specifies how many packets can be queued to a simulator.
SUBNET_SHMKEY
Alias: shmkey Default: IP address Specifies the shared memory key.
Option Parameters:
SUBNET_BROADCAST
Alias: broadcast Default: yes Specifies whether to allow MAC broadcast packets.
SUBNET_MULTICAST
Alias: multicast Default: yes Specifies whether to allow multicast packets.
SUBNET_ERRORRATE
Alias: errorrate Default Value: DEFAULT_ERRORRATE Defines the subnet error rate (the percentage of packet loss on this subnet)
62
Table 5-2
Parameter
Description
SUBNET_TIMEOUT
Alias: timeout Default Value: DEFAULT_TIMEOUT Defines how long packets that are queued are left in the queue before garbage collection removes them.
SUBNET_MTU
Alias: mtu Default Value: 1500 Defines the MTU value that a VxWorks simulator instance is configured to use when it attaches to a subnet.
SUBNET_EXTCONNNAME
Alias: extconnname Default: Specifies the network interface name to use for this subnet as set in Control Panel > Network Connections (Windows only).
Configuring Multiple External Subnets
The VxWorks simulator network daemon can be configured with multiple external subnets. However, the following caveats should be observed: On Windows hosts: You must install a VxWorks simulator host connection driver (WRTAP) for each external subnet. (For information on installing and configuring the WRTAP driver, see 5.2.3 Installing the Host Connection Driver, p.63.) You may also want to specify a name for the WRTAP device driver used by a given subnet through the SUBNET_EXTCONNNAME configuration parameter. On Solaris and Linux hosts: You must specify the device number of all but the first external subnet using the SUBNET_EXTDEVNUM parameter.
5.2.3 Installing the Host Connection Driver

This section provides instructions for installing the optional VxWorks simulator host connection driver. You only need to install this driver if you want to set up an externally visible subnet (able to communicate with or through the host) of VxWorks simulator instances. After this host driver is installed, vxsimnetd automatically configures its IP address and mask according to the configuration file. Packet sniffers such as tcpdump, snoop, or ethereal can then be attached to the host interface to monitor traffic on the internal simulated subnet.
NOTE: If you are working on a Windows host, installing the host connection driver (the WRTAP or TAP-Win32 driver) can have an impact on your host system performance. Before installing this driver, review the information in Managing the WRTAP Driver on Windows Hosts, p.67.
63
32-Bit Windows Hosts
Use the following instructions to install the WRTAP driver on 32-bit Windows XP, Windows Vista, or Windows 7 hosts. For 64-bit hosts, see 64-Bit Windows Hosts, p.65.
NOTE: If you intend to use more than one external subnet, repeat the installation
steps in the appropriate section below for each subnet. You must install and configure a WindRiver WRTAP driver individually for each subnet that is marked as external. For more information on using the WRTAP driver on Windows hosts, see Managing the WRTAP Driver on Windows Hosts, p.67.
32-Bit Windows XP
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Open the Control Panel. Double-click Add Hardware to open the Add Hardware Wizard, click Next. Answer Yes, I have already connected the hardware, click Next. Select Add a new hardware device (you may need to scroll down to see this option), click Next. Select Install the hardware that I manually select from a list (Advanced). Click Next. Select Network Adapters, click Next. Click the Have Disk... button. Browse to installDir\vxworks-6.x\host\x86-win32\bin (installDir is the name of your VxWorks installation directory). Select wrtap.inf and click Open. Click OK to select the directory. Select WindRiver WRTAP, click Next. Click Next to start installing the driver. Click Continue Anyway in the Hardware installation pop-up window. Click Finish to close the wizard.
32-Bit Windows Vista
1. 2. 3. 4. 5. 6. 7.
Open the Control Panel and select the classic view. Double-click Add Hardware to open the Add Hardware Wizard, click Next. Select Install the hardware that I manually select from a list (Advanced). Click Next. Select Network Adapters, click Next. Click the Have Disk... button. Browse to installDir\vxworks-6.x\host\x86-win32\bin (installDir is the name of your VxWorks installation directory).
64
8. 9. 10. 11. 12.
Select wrtap.inf and click Open. Click OK to select the directory. Select WindRiver WRTAP, click Next. Click Next to start installing the driver. Click Finish to close the wizard.
32-Bit Windows 7
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Select Start. Right-click your computer and select Manage. On the left-hand side, select Device Manager. In the middle panel of the resulting window, right-click the computers hostname and select Install legacy hardware. Select Install the hardware I manually select from a list and click Next. Select Network Adapters. Click Have Disk. Browse to installDir\vxworks-6.x\host\x86-win32\bin (installDir is the name of your VxWorks installation directory). Select wrtap.inf and click Open. Click OK to select the directory. Select WindRiver WRTAP, click Next. Click Next to start installing the driver. Click Finish to close the wizard.
64-Bit Windows Hosts
To set up an externally visible subnet through a 64-bit Windows host, you must install the TAP-Win32 driver. The TAP-Win32 driver is distributed as a part of the OpenVPN application. You must install it separately from Wind River Workbench. To install it, do the following: 1. 2. 3. Go to http://openvpn.net/ and find the download options for OpenVPN 2.0. Choose the download method that uses Windows Installer. In the OpenVPN Setup Wizard, deselect all components except the TAP-Win32 Virtual Ethernet Adapter. You do not need any other components of OpenVPN. 4. 5. Click Next and then Install Once installation is complete, click Next and then Finish.
65
NOTE: Because the TAP-Win32 driver may be used by several tools, such as
Simics, Wind River recommends you rename the connection to a distinctive string (for example, tap-vxsim). Then use a configuration file to specify the new connection name that the network daemon should use. For example:
SUBNET_START default { SUBNET_ADDRESS="192.168.200.0"; SUBNET_EXTERNAL = yes; SUBNET_EXT_CONNNAME="tap-vxsim"; };
Then, start the network daemon with this updated configuration file.
Solaris Hosts
To install the VxWorks simulator host connection driver on a Solaris host: 1. 2. 3. 4. 5. Copy installDir/vxworks-6.x/host/sun4-solaris2/bin/tap to a directory accessible by root. Log on with administrator privileges. Go to the directory to which you copied the tap package. Install the tap package as follows:
# pkgadd -d tap
Select the Universal TAP device driver and answer yes to run the install scripts.
Linux Hosts
The tun module required by the TAP driver must be available in your Linux distribution.
NOTE: The tun driver is available by default as part of the core kernel package for Red Hat Enterprise Linux Workstation 4.0 and later versions. It is also available as part of the default distribution for SuSE Linux 9.2. However, the driver is not available in the core kernel package of Red Hat Workstation 3.0, update 4 or earlier.
If you are using an earlier release of Red Hat (prior to Linux kernel version 2.4.21-20), the tun module is part of the kernel-unsupported RPM package. To use the tun module with Red Hat Workstation 3.0, update 4 or earlier, you must update your Linux kernel to version 2.4.21-20 and install the kernel-unsupported RPM package. The tun module should be loaded automatically when vxsimnetd is started. However, some OS versions require you to load the module into the kernel. To do this, first check that the module is present:
$ modinfo tun filename: /lib/modules/2.4.21-20.EL/unsupported/drivers/net/tun.o description: <none> author: <none> license: "GPL"
66
To load the module into the kernel, type the following:

$ modprobe tun
Managing the WRTAP Driver on Windows Hosts
The following information may be useful when installing and using the host connection (WRTAP) driver on a Windows host. For instructions on installing the WRTAP driver, see the 5.2.3 Installing the Host Connection Driver, p.63.
Migrating from the ULIP Driver
The WRTAP driver replaces the ULIP driver used in earlier VxWorks simulator releases. You can use the WRTAP driver even if the ULIP driver is installed.
Handling Networking Problems on Your Host System
If you encounter networking problems with the VxWorks simulator or your host system after installing the WRTAP driver, you may need to make certain changes to your Windows network connection settings.
NOTE: You need administrator privileges on the Windows host to make the
following changes. To access Windows network connection settings, select Start > Control Panel > Network Connections (on Windows XP hosts) or Start > Control Panel > Network and Sharing Center > Manage network conne ctions (on Windows Vista hosts). Certain communication protocols (particularly those which alter the maximum transmission unit (MTU) setting of the interface) can cause problems when the WRTAP driver is in use. In some instances, you may need to remove all protocols except TCP/IP. To do this, right click on each network connection and select Properties. Under the General tab, uncheck all items and components except TCP/IP (Internet Protocol TCP/IP).
NOTE: Removing all protocols except TCP/IP has no impact on the general host
system. The change only applies to the WRTAP interface that is used for communication between the host system and the VxWorks simulator. When you install the WRTAP driver, it becomes the primary network connection type on your host system. This can cause other applications to run slowly and can cause failures on the host system. To replace WRTAP as your main network connection, do the following:
In the Network Connections (or Network and Sharing Center > Manage network connections) window, select Advanced > Advanced Settings... . (On Vista hosts, you need to press the Alt key to access the Advanced menu.) Under the Adapters and Bindings tab, move your main Ethernet interface to the top of the Connections list.
67
Disabling the WRTAP Driver
IP address configuration for the WRTAP network connection is handled automatically by the VxWorks simulator network daemon. However, by default, the WRTAP network connection is turned on immediately following installation and uses DHCP to configure its IP address. To avoid the DHCP configuration, you can disable the WRTAP network connection after installation and allow it to be restarted and configured by the VxWorks simulator network daemon when necessary. To disable the WRTAP network connection, access the Windows network connection settings by selecting Start > Control Panel > Network Connections (on Windows XP hosts) or Start > Control Panel > Network and Sharing Center (on Windows Vista hosts). In the Network Connections (or Network and Sharing Center) window, right-click the WRTAP network interface you want to disable and select Disable. (You can see that an interface is connected using the WRTAP driver by right-clicking and selecting Properties. The device the interface is using is listed in the Connect using field under the General tab.)
5.2.4 Configuring a Simulated Subnet

This section describes how to configure simulated subnets for use with the VxWorks simulator. For information on configuring a subnet using multiple hosts (working with wrnetdlink), see 5.2.5 Configuring a Subnet Across Multiple Hosts Using wrnetdlink, p.69.
Starting a Simulator Instance with Multiple Network Interfaces
If you need to configure a VxWorks simulator instance with multiple network interfaces (a router configuration), vxsim includes the -ni option. The syntax for this option is as follows:
-ni deviceNameDeviceNumber:subnet=IP_address:IP_netmask
This describes one interface. You can chain these descriptions together using a semi-colon (;) as a delimiter. For example:
% vxsim -ni simnet2=192.168.2.1:0xffffff0;simnet3=192.168.3.1:0xffffff0; simnet4=192.168.4.1:0xffffff0
NOTE: When launching the vxsim command from the command line on Linux and Solaris hosts, you must use double quotation marks (") around the -ni option parameter values to prevent the UNIX shell from interpreting the semi-colon (;). For example:
% vxsim -ni "simnet2=192.168.2.1:0xffffff0;simnet3=192.168.3.1:0xffffff0; simnet4=192.168.4.1:0xffffff0"
Double quotes should not be used when passing this option to the command line using Workbench or when using the command line on a Windows host. This command starts a VxWorks simulator instance configured with three simulated network interfaces that link the target with three very small subnets.
68
NOTE: When using the Wind River Workbench New Connection wizard to
launch your VxWorks simulator, the -ni option can be passed to the simulator using the Other VxWorks simulator options field of the VxWorks Simulator Miscellaneous Options dialog.
Starting a Simulator Instance without an IPv4 Address
You can start a VxWorks simulator instance and attach to a subnet through its name. For example, you can use the following commands:
% vxsim -d simnet % vxsim -ni simnet
These commands start a simulator that attaches to the first configured subnet (neither IPv4 address is specified). In this example, a MAC address can no longer be deduced from the IP address so a node number is used instead. The first attaching simulator instance gets 7a:7a:0:0:0:1, and the second instance gets 7a:7a:0:0:0:2, where 7a:7a is the subnet MAC prefix of the first configured subnet.
NOTE: In this example, the MAC address is no longer fixed and can change if the simulator instance is rebooted. This may cause a problem with ARP tables.
You can also use the following command:

% vxsim -ni simnet0:default
Use this command to start a VxWorks simulator instance that attaches to a subnet named default. The MAC address is determined as described in the earlier example. It is also possible to get a fixed MAC address by specifying an IPv4 address that is not used to configure the simnet interface if the component INCLUDE_NET_BOOT_CONFIG is not defined. Thus, you can use the following commands:
% vxsim -d simnet -e 192.168.3.1 % vxsim -ni simnet1=192.168.3.1
This command sequence starts a VxWorks simulator instance with a simulated subnet interface with a MAC address of 7a:7a:c0:a8:03:01 and an IP address (or addresses) that can be configured later using the ifconfig( ) command.
5.2.5 Configuring a Subnet Across Multiple Hosts Using wrnetdlink

If you configure your simulated subnets on a single host using vxsimnetd (as described previously), the number of simulators that can be attached is limited by the processing power and the available memory of the host system. To ease this limitation, Wind River provides the wrnetdlink tool. This tool allows you to link multiple subnets running on any number of multiple hosts by linking the subnets running on each host. Figure 5-3 illustrates this linking.
69
Figure 5-3
Linked Subnet across Multiple Hosts
External Subnet
WRTAP driver
WRTAP driver
vxsimnetd
vxsimnetd
VxSim0
192.168.200.1
VxSim<N>
192.168.200.n
wrnetdlink
VxSim1
192.168.200.2
Simulated subnet0 192.168.200.0 Simulated subnet<N>
Simulated subnet<N> 192.168.200.0
Host 1
Host 2
Therefore, the general workflow for configuring multiple subnets is as follows: 1. 2. Start a network daemon (vxsimnetd) on each host (see 5.2.2 Setting Up the Network Daemon, p.50). Start and configure wrnetdlink.
To start wrnetdlink and configure a multi-host subnet issue the following command from a VxWorks Development Shell:
-> wrnetdlink - net ipAddr1:portNumber1:subnetName1 ... - net ipAddrN:portNumberN:subnetNameN
where ipAddrN is the IP address or host name for the host that is running the network daemon (each host you wish to link must be running a network daemon), portNumberN is the port number that the network daemon uses to accept connections, and subnetNameN is the name of the subnet running on the host. Note that all of the parameters supplied to wrnetdlink are optional. If the parameters are not specified, default values are used instead. The default IP address (ipAddr) is 127.0.0.1 (local host). The default port number (portNumber) is 5555, which is the default value configured by vxsimnetd. The default subnet name is blankif only one subnet on the host is available, it is used by default. Otherwise, the first subnet configured on the host is used. An example command to use the default configuration might be:
-> wrnetdlink - net - net host2
This command links a subnet on the local host to one on host2, using the default settings. You can also start multiple wrnetdlink sessions to connect multiple multi-host subnets.
70
5 Networking with the VxWorks Simulator 5.3 Network Redirection: simnet_nat
5.3 Network Redirection: simnet_nat

As an alternative to the full network simulation described in 5.2 Full Network Simulation: simnet, p.48, the VxWorks simulator also provides support for network redirection (NAT). The VxWorks simulator provides network redirection through the simnet_nat device. On any given VxWorks simulator instance, only one device can be configured. However, you can configure additional simnet devices using the -ni option. For detailed information on the -ni option, see Starting a Simulator Instance with Multiple Network Interfaces, p.68.
5.3.1 Using Default Redirections

The VxWorks simulator stack is responsible for the following process: 1. 2. 3. 4. Intercept all network packets from the VxWorks guest. Analyze them. Filter out non-UDP and -TCP packets. Forward the TCP/UDP packets to the correct destination by creating a UDP/TCP socket on the host.
The VxWorks simulator stack also performs subsequent tasks: 5. 6. 7. Monitor the activity on the newly created UDP/TCP sockets. Fix the headers on any received UDP/TCP packets. Forward those packets to the VxWorks simulator network driver.
No particular setup is necessary in order to access the network from the VxWorks simulator, and port redirections are automatic. When you start the VxWorks simulator and specify simnet_nat as boot device, a number of ports are automatically redirected. Redirections are printed to the console. For example:
Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting Redirecting TCP TCP TCP TCP TCP TCP TCP UDP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP port port port port port port port port port port port port port port port port port port port port port port 58811 58812 58813 58814 58815 58816 58817 44071 58818 58819 58820 58821 58822 58823 58824 58825 58826 58827 58828 58829 58830 58831 to to to to to to to to to to to to to to to to to to to to to to 10.0.10.2:21 10.0.10.2:22 10.0.10.2:23 10.0.10.2:69 10.0.10.2:80 10.0.10.2:443 10.0.10.2:17476 10.0.10.2:17185 10.0.10.2:1534 10.0.10.2:5698 10.0.10.2:5678 10.0.10.2:3333 10.0.10.2:49152 10.0.10.2:49153 10.0.10.2:49154 10.0.10.2:49155 10.0.10.2:49156 10.0.10.2:49280 10.0.10.2:49281 10.0.10.2:49282 10.0.10.2:49283 10.0.10.2:49284
The default port redirections are also listed in a file, vxsim_nat_redirs.txt, located at installDir/vxworks-6.x/host/resource/vxsim/.
71
In the console output above:
Target or guest (that is, VxWorks) TCP port 21 (FTP) can be reached through host TCP port 58811. Target TCP port 22 (SSH) can be reached through host TCP port 58812. Target TCP port 23 (telnet) can be reached through host TCP port 58813, and so on.
So, if VxWorks is configured to provide an SSH or telnet server, you would use the following to reach the target SSH and telnet server, respectively:
ssh -p 58812 hostIp telnet -p 58813 hostIp
Overriding Default Redirections
Default redirections do not specify the host port value, since it is not possible to obtain a value that will always be available. This means that in the example in the previous section, the values of 58811, 58812, and 58813 might change if the simulator is restarted. However, you can overwrite the default configuration by specifying a new guest port configuration. To do so, use the VxWorks simulator command-line option -add_nat_redir. The command-line setting overrides the default configuration. For details on the -add_nat_redir option, see Table 2-2 and 5.3.2 Adding a Network Redirection, p.72.
5.3.2 Adding a Network Redirection

Besides the default redirections that are automatically performed, you can add a custom redirection, such as to connect a custom server application that is running on the simulator. You can do this either from the command line or within Wind River Workbench.
From the Command Line
To add a network redirection from the command line, use the -add_nat_redir (or -anr) option. The syntax for this option is as follows:
-add_nat_redir udp|tcp:guestPortNumber[[:hostPortNumber[:portName]]
udp Redirect a UDP port. tcp Redirect a TCP port. guestPortNumber The port number of the guest port you want to access. hostPortNumber The host port number that will be used to access the specified guestPortNumber. An optional parameter. If you do not define hostPortNumber, the VxWorks simulator automatically allocates a port number.
72
5 Networking with the VxWorks Simulator 5.3 Network Redirection: simnet_nat
portName A string that Wind River Workbench uses to identify the ports purpose when the host port number may vary. You can use this string so that you dont have to remember the port number. To specify multiple redirections, separate them with a semicolon character ( ; ).
Examples
udp:0x4321:2000
Redirects guest UDP port 0x4321 to host UDP port 2000.

udp:0x4321
Redirects guest UDP port 0x4321 to a random host UDP port.

udp:0x4321;tcp:23
Redirects guest UDP port 0x4321 and guest TCP port 23 to random host UDP and TCP ports.
From Workbench
To add a network redirection in Workbench, do the following: 1. 2. 3. 4. Go to the Target Connection Properties. Select the Network Options tab. Select Network using NAT (simnet_nat) and click Add. In the dialog that appears, specify the desired protocol, remote port (guest port), local port (host port), and redirection name.
5.3.3 Listing Network Redirections

It can be useful to view the list of redirected ports for a particular VxWorks simulator instancefor example, as part of a script. You can get the full list of redirections through the -list_nat_redir (or -lnr) command-line option to the simulator. To identify which VxWorks simulator instance you want information about, use the -p option to specify the corresponding processor number. For example:
% vxsim -list_nat_redir -p 0 tcp:23:2000:telnet
Windows Hosts
On Windows hosts, the results of -list_nat_redir are not printed to standard output. To view the output, use the -l option to save the simulators output to a file, and then read the contents of the file. For example:
C:\WINDOWS>vxsim -list_nat_redir -l %TEMP%\output.txt -lc -p 0 C:\WINDOWS>cat %TEMP%\output.txt tcp:23:2000:telnet
73
5.3.4 Limitations
The VxWorks simulators network redirection capability has the following limitations:
While you can start several VxWorks simulator instances using the simnet_nat device on the same host, when you do so each port redirection must be different. That is, multiple simulator instances cannot use the same host port. The network redirection facility supports IPv4 and TCP/UDP packets only. It does not support IPv6. You can configure the VxWorks simulator to include both simnet_nat and simnet devices, or you can configure it with a simnet_nat device only. In either case, however, in order to use network redirection, the simnet_nat device must be your boot device. You cannot add a simnet_nat device through the -ni command-line option. The simnet_nat device cannot be manually loaded from VxWorks. You cannot change the gateway IP address and simnet_nat network device IP address from VxWorks. Multiple instances of the VxWorks simulator that are configured to include network redirection cannot communicate using the network-redirection IP addresses (10.0.10.x). However, a single redirection-enabled simulator instance can access an IP port on another redirection-enabled simulator instance by means of the host IP address and the host redirected port.
74
6
Networking Tutorials
6.1 Introduction 75 6.2 Simple Simulated Network 76 6.3 Basic Simulated Network with Multiple Simulators 79 6.4 Networking Across Multiple Hosts with wrnetdlink 89 6.5 Adding a VxWorks Simulator to a Local Network 93 6.6 IPv6 Tutorial 97
6.1 Introduction
This chapter presents tutorials that provide step-by-step instruction for setting up a variety of simulated networks with VxWorks simulator instances. The following tutorials are presented:
NOTE: Workbench instructions in this chapter assume that the Workbench
Advanced Device Development perspective is displayed. The title bar at the upper left of the Workbench window shows the current perspective. To display the Advanced Device Development perspective, select Window > Open Perspective > Advanced Device Development.
Simple simulated networkTutorial to set up a simple network connection between the host system and a single simulator instance. Simulated network with multiple simulator instancesTutorials for setting up a basic network with multiple simulators using both static and interactive configuration methods for the VxWorks simulator network daemon (vxsimnetd). Networking across multiple hostsTutorial illustrating how the wrnetdlink tool can be used to configure subnets across multiple host systems. Adding a VxWorks simulator to a local networkTutorial to demonstrate how to plug the VxWorks simulator directly into a local network through a bridge configured on the host system.
75
IPv6Tutorial to demonstrate how to configure a VxWorks simulator network with IPv6 support.
Most of the tutorials in this chapter demonstrate network simulation using the ping( ) routine.
NOTE: When launching the vxsim command from the command line on Linux and Solaris hosts (as instructed in the tutorials throughout this chapter), you must use double quotation marks (") around the -ni option parameter values to prevent the UNIX shell from interpreting the semi-colon (;). For example, the following line:
% vxsim -ni simnet2=192.168.200.1;simnet3=192.168.3.1;simnet4=192.168.4.1
should be executed as follows when using the Linux or Solaris command-line interface:
% vxsim -ni "simnet2=192.168.200.1;simnet3=192.168.3.1;simnet4=192.168.4.1"
Double quotation marks should not be used when passing options to the command line using Workbench or when using the command line on a Windows host.
6.2 Simple Simulated Network

The most basic (and common) network used by the VxWorks simulator is a network set up between the host and a single VxWorks simulator instance. You can set up this simple network using the default VxWorks simulator configuration. Therefore, the following tutorial does not require you to reconfigure or rebuild the default VxWorks image provided with the VxWorks simulator BSP. This tutorial describes how to: 1. 2. 3. Set up and start the VxWorks simulator network daemon (vxsimnetd). Start a single VxWorks simulator instance. Test the simulator network by pinging the VxWorks simulator instance from the host.
This tutorial can be performed with any supported host using the command-line utility, vxprj, or Wind River Workbench.
6.2.1 Set Up the Network Daemon

The first step in setting up a VxWorks simulator network is to start the network daemon. For this tutorial, start the network daemon on the host before you configure any VxWorks simulator instances.
Installing the VxWorks Simulator Host Connection Driver
Before configuring and starting the VxWorks simulator network daemon, you must install the VxWorks simulator host connection driver (WRTAP driver). If you have not already installed the host connection driver, do so now. Instructions for all supported hosts are provided in 5.2.3 Installing the Host Connection Driver, p.63.
76
6 Networking Tutorials 6.2 Simple Simulated Network
Configuring the Network Daemon
This tutorial uses the default configuration for the VxWorks simulator network daemon. Therefore, vxsimnetd can be started without any options and no custom configuration file is required.
NOTE: The default configuration uses a default subnet of 192.168.200.0. If this
subnet already exists on your host, you must change the VxWorks simulator network daemon configuration file. For more information on the default configuration options as well as other network daemon configuration file options, see Creating a Network Daemon Configuration File, p.59.
Starting the Network Daemon on the Host System NOTE: Wind River recommends that you start vxsimnetd as a service. For
complete instructions, see Starting the Network Daemon as a Service, p.51. If you have already started the default vxsimnetd as a service or choose to do so now, you can skip the instructions in this section. To start the VxWorks simulator network daemon in the default configuration: On Windows hosts: 1. 2. 3. Log in as administrator or be sure you have administrator privileges. Open a Windows command shell (Start > Run..., then type cmd). In the command shell, type the following:
C:\> installDir\vxworks-6.x\host\x86-win32\bin\vxsimnetd
where installDir is the name of your VxWorks installation directory. On Linux hosts: 1. 2. Open a host shell and log in as root. In the host shell, type the following:
$ installDir/vxworks-6.x/host/x86-linux2/bin/vxsimnetd
where installDir is the name of your VxWorks installation directory. On Solaris hosts: 1. 2. Open a host shell and log in as root. In the host shell, type the following:
# installDir/vxworks-6.x/host/sun4-solaris2/bin/vxsimnetd
where installDir is the name of your VxWorks installation directory.
6.2.2 Start a VxWorks Simulator Instance

Next, you need to start a VxWorks simulator instance from the command line in the VxWorks Development Shell or from the Workbench New Target Connection wizard. Again, the default VxWorks configuration is used for this tutorial, therefore, you do not need to reconfigure or rebuild the default VxWorks image for the VxWorks simulator.
77
Start the Simulator Instance from the Command Line
To start a VxWorks simulator instance from the command line, do the following: 1. Open the VxWorks Development Shell. On Windows hosts, select Start > Wind River > VxWorks 6.x and General Purpose Technologies > Vx Works Development Shell. On Solaris and Linux hosts, run the wrenv utility program to open a development shell as follows:
% wrenv.sh -p vxworks-6.x
2.
In the VxWorks Development Shell, type the following: On Windows hosts:

C:\> vxsim -d simnet -e 192.168.200.1 -f installDir\vxworks-6.x\target\config\simpc\vxWorks
where installDir is the name of your VxWorks installation directory. On Linux or Solaris hosts:
% vxsim -d "simnet" -e "192.168.200.1" -f "installDir/vxworks-6.x/target/config/bsp/vxWorks"
where installDir is the name of your VxWorks installation directory and bsp is the name of the BSP directory for the VxWorks simulator on your host (linux for Linux hosts or solaris for Solaris hosts). The above command starts a VxWorks simulator instance and attaches it to the default subnet. The VxSim0 console windows appears.
Start the Simulator Instance from Workbench
To start the VxWorks simulator instance from Workbench, complete the following steps: 1. 2. Select Target > New Connection.... This launches the New Connection wizard. In the Connection Type dialog box, select Wind River VxWorks 6.x Simulator Connection from the selection list. Click Next. In the Select boot file name field of the VxWorks Boot parameters dialog, click the Standard simulator (Default) radio button (this option should be selected by default). This selects the default VxWorks image for the VxWorks simulator. Enter 0 in the Processor Number field (this is the default value). Click the Advanced Boot Parameters... button. In the boot device field, select simnet from the drop down list. In the Inet on ethernet (e) field, enter 192.168.200.1 (this is the default value). Leave all other fields with their default settings. Click OK. This returns you to the VxWorks Boot parameters dialog of the New Connection wizard, click Next. The VxSim Memory Options dialog appears. Click Next to accept the default options.
3.
4. 5.
6.
78
6 Networking Tutorials 6.3 Basic Simulated Network with Multiple Simulators
7. 8. 9. 10. 11. 12.
The VxWorks Simulator Miscellaneous Options dialog appears. Click Next to accept the default options (most options are blank by default). The Target Server Options dialog appears. Click Next to accept the default options. The Object Path Mappings dialog appears. Click Next to accept the default options. The Target State Refresh dialog appears. Click Next to accept the default options. The Debug Options dialog appears. Click Next to accept the default options. The Connection Summary dialog appears. Click Finish.
This boots VxWorks on the simulator target and launches the VxSim0 console window. If your target connection fails or you encounter problems during configuration, see the Wind River Workbench By Example: Connecting to VxWorks Targets for more information.
6.2.3 Test the Simulated Network

To test that the simulated network is working, ping the simulator instance from your host system. From a host command window or shell, type:
% ping 192.168.200.1
6.3 Basic Simulated Network with Multiple Simulators

The following tutorials present the steps required to set up a simulated network with multiple VxWorks simulator instances. Two configuration options are described. The first tutorial creates a subnet with a static configuration. The second tutorial launches the VxWorks simulator network daemon (vxsimnetd) in interactive mode. The interactive mode starts a vxsimnetd shell that allows you to dynamically configure and monitor the subnet. (For more information on the VxWorks simulator network daemon, see 5.2.2 Setting Up the Network Daemon, p.50.) The following tutorials require you to configure and build a new VxWorks image for the VxWorks simulator. The steps required to build and configure the image are included in this tutorial. However, if you require more information on building and configuring VxWorks, see Wind River Workbench By Example: Configuring and Building VxWorks and the users guide for your Platform.
79
6.3.1 Creating a Static Configuration

The following tutorial takes you through the steps of creating a simulated network with a static configuration. The general workflow is as follows: 1. 2. 3. 4.
Step 1:
Configure and launch the VxWorks simulator network daemon (vxsimnetd). Configure and build a VxWorks image for use with the VxWorks simulator instances. Launch the required simulator instances. Run the ping application.
Configure and Launch vxsimnetd
1.
The first step in setting up your simulated network is to set up and start vxsimnetd. Before completing the following steps, be sure that you have:
Installed the VxWorks simulator host connection driver (WRTAP driver). (Instructions for installing the driver are available in 5.2.3 Installing the Host Connection Driver, p.63.) Stopped any previously started VxWorks simulator network daemons (including those started as a service, see Starting the Network Daemon as a Service, p.51).
2.
Create a vxsimnetd configuration file. For the purposes of this tutorial, this file is used to configure the network for use with a simulated router (see Configure and Start the Simulated Router, p.83). Create the following file and save it as vxsimTest.conf:
SUBNET_START sub2 { SUBNET_ADDRESS = "192.168.200.0"; SUBNET_EXTERNAL = yes; SUBNET_EXTPROMISC = yes; }; SUBNET_START sub3 { SUBNET_ADDRESS = "192.168.3.0"; SUBNET_EXTERNAL = no; }; SUBNET_START sub4 { SUBNET_ADDRESS = "192.168.4.0"; SUBNET_EXTERNAL = no; };
3.
Launch vxsimnetd using the configuration file you just created. On Windows hosts: Log in with administrator privileges and start vxsimnetd from a command window as follows:
C:\> installDir\vxworks-6.x\host\x86-win32\bin\vxsimnetd -f vxsimTest.conf
Be sure to provide the full path to your vxsimTest.conf file if it is not in your current directory. On Linux and Solaris hosts: Log in as root and start vxsimnetd from a host shell as follows:
# installDir/vxworks-6.x/host/myHost/bin/vxsimnetd -f vxsimTest.conf
In this command, myHost is your host type: x86-linux2 for Linux hosts or sun4-solaris2 for Solaris hosts.
80
Be sure to provide the full path to your vxsimTest.conf file if it is not in your current directory.
NOTE: You can also start vxsimnetd as a service. For instructions, see Starting the
Network Daemon as a Service, p.51. If you choose to start vxsimnetd as a service, you will need to configure the daemon as directed in this section (by passing the -f option to the service) before proceeding with the tutorial.
NOTE: If you do not start vxsimnetd with administrator (or root) privileges, vxsimnetd prints a warning. In this case, you will not be able to connect the host system to the simulated network. However, all other simulated network functionality is available. Step 2: Prepare a VxWorks Image for Use with the Simulated Network
In this tutorial, the VxSim0 simulator instance acts as a router. This tutorial uses ping to communicate between simulator instances, therefore, ping functionality must be enabled. Because this functionality is not included in the default VxWorks image, you must configure and build a new VxWorks image for use with the simulated network. To properly configure the VxWorks image, you must include the
INCLUDE_ROUTECMD and INCLUDE_PING components in your custom
VxWorks image. Once this configuration is in place, you must rebuild the VxWorks image for the simulator.
Prepare Your VxWorks Image Using the vxprj Command-Line Utility
To reconfigure the VxWorks image with the necessary components using the command-line project facility, vxprj, complete the following steps: 1. Generate a project. This can be done from the command line as follows: In the VxWorks Development Shell, type the following: On Windows hosts:
C:\> vxprj create simpc TOOL network_demo
where TOOL is your chosen compiler (diab for the Wind River Diab Compiler or gnu for the GNU compiler). On Linux hosts:
$ vxprj create linux TOOL network_demo
where TOOL is your chosen compiler (diab for the Wind River Diab Compiler or gnu for the GNU compiler). On Solaris hosts:
% vxprj create solaris TOOL network_demo
where TOOL is your chosen compiler (diab for the Wind River Diab Compiler or gnu for the GNU compiler). This creates a project directory under installDir with the name network_demo. 2. Add the INCLUDE_ROUTECMD and INCLUDE_PING components to the image:
% cd network_demo % vxprj component add INCLUDE_ROUTECMD INCLUDE_PING
81
3.
Rebuild VxWorks. In the project directory (installDir/network_demo), execute make.
Prepare Your VxWorks Image Using Workbench
1.
Create a VxWorks image project. The following steps assume that the Workbench Advanced Device Development perspective is displayed. The title bar at the upper left of the Workbench window shows the current perspective. To display the Advanced Device Development perspective, select Window > Open Perspective > Advanced Device Development. a. b. In Workbench, select File > New > VxWorks Image Project. This launches the New VxWorks Image Project wizard. In the Project dialog, enter network_demo in the Project name field. Select the location for your project in the Location field (Create Project in Workspace is selected by default). Click Next. In the Project Setup dialog, select the option to set up your project based on a board support package (this option is selected by default). Select the appropriate VxWorks simulator BSP for your host (for example, simpc on Windows hosts) and your desired tool chain (for example, diab for the Wind River Diab Compiler). Click Next.
c.
d. In the Options dialog, click Next to accept the default options (no options are selected by default). e. In the Configuration Profile dialog, select (no profile) from the Profile drop-down list (this is the default). Click Finish.
This creates a project directory with the name, network_demo. The new project appears in the Project Navigator pane on the left. 2. Configure a custom VxWorks kernel to include the appropriate networking components. a. Expand the new network_demo project and right-click Kernel Configuration. Select Edit Kernel Configuration. This opens the component configuration tool in the center pane of the Application Development window. Select the Components tab at the bottom of the kernel configuration pane (if it is not already selected). Right-click in the component configuration field and select Find. Use the Find tool to locate the INCLUDE_ROUTECMD and INCLUDE_PING components. To find a component, type the component name (for example, INCLUDE_PING) in the Pattern field. When the component appears in the Matching list, select the component and click the Find button. This returns you to the component configuration tool. The selected component is highlighted in the component tree. Right-click the selected component and select Include (quick include).
b.
c.
d. Right-click in the component tree and select Save. 3. Build your project. a. Now, right-click on the network_demo project in the Project Navigator (upper left pane) and select Build Project (this executes the make
82
command in the project directory). The build output appears in the Build Console (lower right pane).
Step 3: Launch the VxWorks Simulator Instances
Start the simulator instances to attach to the configured subnets. This results in a simulated network with the following topology:
Host
192.168.200.254 VxSim0 (router) 192.168.200.1 simnet2 VxSim1
192.168.200.2
VxSim2 192.168. 3.1 simnet3 VxSim3 192.168.4.1 simnet4
192.168.3.2
192.168.4.2
You can launch the simulator instances from the VxWorks Development Shell using the command line, or from Workbench.
Start the VxWorks Simulator Instances from the Command Line
If you have not already done so, change to the directory where you built your VxWorks image (for example, installDir/network_demo/default).
Configure and Start the Simulated Router
To configure the VxWorks simulator instance for the simulated router, type the following in the VxWorks Development Shell:
-> vxsim -ni simnet2=192.168.200.1;simnet3=192.168.3.1;simnet4=192.168.4.1
This command sets up a network interface for the router on each subnet so that it can properly forward packets. Once you execute this command, the VxSim0 console window appears. (The VxSim0 instance acts as the simulated router.)
83
Configure and Start the Simulated Network Instances
To configure three VxWorks simulator instances on the simulated network, type the following in the VxWorks Development Shell:
-> vxsim -d simnet -e 192.168.200.2 -p 1 -> vxsim -d simnet -e 192.168.3.2 -p 2 -> vxsim -d simnet -e 192.168.4.2 -p 3
This command creates three instances on the simulated network; VxSim1, VxSim2, and VxSim3. One node is created on each of the three subnets you set up when you launched vxsimnetd (see Step 1:Configure and Launch vxsimnetd, p.80).
Start the VxWorks Simulator Instances from Workbench
This section provides instructions for launching the simulated router and networked VxWorks simulator from Workbench using the Advanced Device Development perspective.
Configure and Start the Simulated Router
Start the VxWorks simulator instance that will act as the router in the simulated network. To start this instance from Workbench, complete the following steps: 1. 2. Select Target > New Connection.... This launches the New Connection wizard. In the Connection Type dialog box, select Wind River VxWorks 6.x Simulator Connection from the selection list. Click Next. In the Select boot file name field of the VxWorks Boot parameters dialog, click the Custom simulator radio button. Browse to your project location and click Open to select your VxWorks image (for example, installDir/workspace/network_demo/default/vxWorks). Enter 0 in the Processor Number field. Click Next. The VxSim Memory Options dialog appears. Click Next to accept the default options. The VxWorks Simulator Miscellaneous Options dialog appears. In the Other VxWorks simulator options field, enter:
-ni simnet2=192.168.200.1;simnet3=192.168.3.1;simnet4=192.168.4.1
3.
4. 5. 6.
This option sets up a network interface for the router on each subnet so that it can properly forward packets. Click Next. 7. 8. 9. 10. 11. The Target Server Options dialog appears. Click Next to accept the default options. The Object Path Mappings dialog appears. Click Next to accept the default options. The Target State Refresh dialog appears. Click Next to accept the default options. The Debug Options dialog appears. Click Next to accept the default options. The Connection Summary dialog appears. Click Finish.
84
This boots VxWorks on a simulator target and launches the VxSim0 console window. VxSim0 acts as a router on the simulated network.
Configure and Start the Simulated Network Instances
Configure three VxWorks simulator instances, one instance per subnet (repeat the following process for each of the three instances). To configure each of the devices, complete the following steps: 1. 2. Select Target > New Connection.... This launches the New Connection wizard. In the Connection Type dialog box, select Wind River VxWorks 6.x Simulator Connection from the selection list. Click Next. In the Select boot file name field of the VxWorks Boot parameters dialog, click the Custom simulator radio button. Browse to your project location and click Open to select your VxWorks image (for example, installDir/workspace/network_demo/default/vxWorks). Enter 1 in the Processor Number field. (Enter 2 for this option when starting the second instance and 3 when starting the third instance.) Click the Advanced Boot Parameters... button. In the boot device field, select simnet from the drop down list. In the Inet on ethernet (e) field, enter 192.168.200.2. (Enter 192.168.3.2 when starting the second instance and 192.168.4.2 when starting the third instance). Leave all other fields with their default settings. Click OK. This returns you to the VxWorks Boot parameters dialog of the New Connection wizard. Click Next. The VxSim Memory Options dialog appears. Click Next to accept the default options. The VxWorks Simulator Miscellaneous Options dialog appears. Click Next to accept the default options (most options are blank by default). The Target Server Options dialog appears. Click Next to accept the default options. The Object Path Mappings dialog appears. Click Next to accept the default options. The Target State Refresh dialog appears. Click Next to accept the default options. The Debug Options dialog appears. Click Next to accept the default options. The Connection Summary dialog appears. Click Finish.
3.
4. 5.
6. 7. 8. 9. 10. 11. 12.
Repeat this process three times to create three VxWorks simulator instances, VxSim1, VxSim2, and VxSim3. This results in a node being configured on each of the three subnets you set up when you launched vxsimnetd (see Step 1:Configure and Launch vxsimnetd, p.80).
85
Step 4:
Set Up the Routing Table
Before pinging between simulator instances, you must set up the routing table for the simulated network. In the VxSim1 shell, type the following:
-> routec ("add -net 192.168.3.0/24 192.168.200.1"); -> routec ("add -net 192.168.4.0/24 192.168.200.1");
In the VxSim2 shell, type the following:

In the VxSim3 shell, type the following:

NOTE: These route settings can be saved in files and run automatically. To do this, specify the saved file as a startup script when invoking vxsim from the command line as follows:
% vxsim -d simnet -e 192.168.200.2 -p 1 -s filename
where filename is the name of your startup script. You can also specify the startup script when launching the simulator from Workbench by adding the startup script to the startup script (s) field in Advanced Boot Parameter Options.
Step 5: Run the Ping Application
To verify the network connections, ping VxSim3 and VxSim2 from VxSim1 as follows:
-> ping "192.168.3.2", 5 -> ping "192.168.4.2", 5
6.3.2 Creating a Dynamic Configuration Using the vxsimnetd Shell

The following steps demonstrate how to dynamically configure the VxWorks simulator using the network daemon shell.
NOTE: This tutorial is an extension of the static configuration tutorial presented in 6.3.1 Creating a Static Configuration, p.80. You must use the VxWorks image you created in the earlier tutorial to launch the VxWorks simulator instances in this tutorial. Step 1: Launch the vxsimnetd Shell Server
Before launching a the vxsimnetd shell server, be sure to kill all previously started VxWorks simulator instances and then kill the previously started network daemon. 1. Start the vxsimnetd shell server. From the command shell on Windows or the host shell on Linux or Solaris, start vxsimnetd with the -sv option as follows:
# installDir\vxworks-6.x\host\myHost\bin\vxsimnetd -sv
86
NOTE: You must start vxsimnetd with administrator (or root) privileges. Once
vxsimnetd is started, administrator privileges are no longer required.

Step 2: Configure vxsimnetd Dynamically Using the Shell
1.
To configure vxsimnetd using the shell, you must create an additional subnet configuration file. Create and save the following file:
SUBNET_START sub3 { SUBNET_ADDRESS = "192.168.3.0"; SUBNET_EXTERNAL = no; }; SUBNET_START sub4 { SUBNET_ADDRESS = "192.168.4.0"; SUBNET_EXTERNAL = no; };
2. 3.
Save this file as sub_3_4.conf. Connect to the vxsimnetd shell. From the host shell, type the following:
% telnet yourHostName 7777
where yourHostName is the name of your host machine. The vxsimnetd debug shell appears. 4. Source the new configuration file as follows:
vxsimnetd> source /myDir/sub_3_4.conf Subnet(s) <sub3, sub4> added.
Step 3:
Prepare a VxWorks Image
If you have not already done so, prepare a VxWorks image according to the instructions in Step 2:Prepare a VxWorks Image for Use with the Simulated Network, p.81.
NOTE: If you have already completed the tutorial in 6.3.1 Creating a Static
Configuration, p.80, you can use the VxWorks image you prepared in the network_demo project.
Step 4: Launch the VxWorks Simulator Instances
Launch the VxWorks simulator instances as described in Step 3:Launch the VxWorks Simulator Instances, p.83. Again, this sets up a simulated network with the following topology:
87
Host
192.168.200.254 VxSim0 (router) 192.168.200.1 VxSim1
192.168.200.2
VxSim2 192.168. 3.1
192.168.3.2
VxSim3 192.168.4.1
192.168.4.2
Step 5:
Set Up the Routing Table
In the current configuration, VxSim2 is configured to be externally available so it can be pinged from the host. However, before pinging the host, you must add the appropriate route information. First, provide the appropriate routing information on your host system.
NOTE: To run the following route commands, you must have administrator
privileges on Windows and supervisor privileges on UNIX. For Windows hosts: Type the following from the Windows command shell:
C:\> route add 192.168.3.0 MASK 255.255.255.0 192.168.200.1 C:\> route add 192.168.4.0 MASK 255.255.255.0 192.168.200.1
For Solaris and Linux hosts: Type the following from the host shell:
% route add -net 192.168.3.0 192.168.200.1 % route add -net 192.168.4.0 192.168.200.1
Next, add the appropriate routing information to the VxSim2 instance. In the VxSim2 console, type the following:
-> routec ("add -net 192.168.200.0/24 192.168.3.1");
Now, add the appropriate routing information to the VxSim3 instance. In the VxSim3 console, type the following:
-> routec ("add -net 192.168.200.0/24 192.168.4.1");
88
6 Networking Tutorials 6.4 Networking Across Multiple Hosts with wrnetdlink
Step 6:
Run the Ping Application
Verify the network connection by pinging VxSim2 and VxSim3 from the host shell as follows:
% ping 192.168.3.2 % ping 192.168.4.2
6.4 Networking Across Multiple Hosts with wrnetdlink

This tutorial describes how to set up a simulated network across multiple hosts. The tutorial begins by starting two simulated subnets, one on each of two separate host systems. The tutorial then illustrates how to link the simulated subnets using wrnetdlink. The following figure shows the network topology for this tutorial:
Real Subnet
Host 1 vxsimnetd vxsimnetd
Host 2
VxSim1 192.168.200.1 wrnetdlink
VxSim2 192.168.200.2
Simulated subnet0 192.168.200.0
Simulated subnet0 192.168.200.0
Note that this tutorial makes a connection between two host systems but any number of host systems can be connectedor chained togetherin a similar fashion. Also note that the host systems can be of any supported host type. For example, you can connect a Windows host to a Linux host.
6.4.1 Set Up the Network Daemon on Each Host

Before connecting the hosts, you must configure and launch the network daemon (vxsimnetd) on each host. To set up the daemon on each host using a static configuration file, do the following: 1. Before starting the network daemon on each host, be sure that you have done the following:
Installed the VxWorks simulator host connection driver (WRTAP driver) on each host. Note that the WRTAP driver is required for the purposes of
89
this tutorial. However, WRTAP is not a requirement for using wrnetdlink, assuming that you do not require connectivity with the host system. For more information and installation instructions, see 5.2.3 Installing the Host Connection Driver, p.63.
Stopped any previously started VxWorks simulator network daemons on each host (including those started as a service, see Starting the Network Daemon as a Service, p.51).
2.
Launch vxsimnetd on each host with the default configuration. On Windows hosts: a. b. c. Log in as administrator or be sure you have administrator privileges. Open a Windows command shell (Start > Run..., then type cmd). In the command shell, type the following:
C:\> installDir\vxworks-6.x\host\x86-win32\bin\vxsimnetd
where installDir is the name of your VxWorks installation directory. On Linux hosts: a. b. Open a host shell and log in as root. In the host shell, type the following:
$ installDir/vxworks-6.x/host/x86-linux2/bin/vxsimnetd
where installDir is the name of your VxWorks installation directory. On Solaris hosts: a. b. Open a host shell and log in as root. In the host shell, type the following:
# installDir/vxworks-6.x/host/sun4-solaris2/bin/vxsimnetd
where installDir is the name of your VxWorks installation directory.
6.4.2 Configure a VxWorks Image on Each Host

You must properly configure a custom VxWorks image on each host for use with this tutorial. The custom image should include the INCLUDE_ROUTECMD and INCLUDE_PING components.
NOTE: If you already generated a custom VxWorks image as directed in 6.3 Basic
Simulated Network with Multiple Simulators, p.79, you can use that image for this tutorial and skip to 6.4.3 Start a Simulator Instance on Each Host, p.92. Otherwise, follow the instructions below.
Prepare Your VxWorks Image Using the vxprj Command-Line Utility
To reconfigure the VxWorks image with the necessary components using the command-line project facility, vxprj, complete the following steps: 1. Generate a project. This can be done from the command line as follows: In the VxWorks Development Shell, type the following: On Windows hosts:
C:\> vxprj create simpc TOOL netdlink_demo
90
6 Networking Tutorials 6.4 Networking Across Multiple Hosts with wrnetdlink
where TOOL is your chosen compiler (diab for the Wind River Diab Compiler or gnu for the GNU compiler). On Linux hosts:
$ vxprj create linux TOOL netdlink_demo
where TOOL is your chosen compiler (diab for the Wind River Diab Compiler or gnu for the GNU compiler). On Solaris hosts:
% vxprj create solaris TOOL netdlink_demo
where TOOL is your chosen compiler (diab for the Wind River Diab Compiler or gnu for the GNU compiler). This creates a project directory under installDir with the name, netdlink_demo. 2. Add the INCLUDE_ROUTECMD and INCLUDE_PING components to the image:
% cd netdlink_demo % vxprj component add INCLUDE_ROUTECMD INCLUDE_PING
3.
Rebuild VxWorks. In the project directory (installDir/netdlink_demo), execute make.
Prepare Your VxWorks Image Using Workbench
1.
Generate a project. a. b. In Workbench, select File > New > VxWorks Image Project. This launches the New VxWorks Image Project wizard. In the Project dialog, enter netdlink_demo in the Project name field. Select the location for your project in the Location field (Create Project in Workspace is selected by default). Click Next. In the Project Setup dialog, select the option to set up your project based on a board support package (this option is selected by default). Select the appropriate VxWorks simulator BSP for your host (for example, simpc on Windows hosts) and your desired tool chain (for example, diab for the Wind River Diab Compiler). Click Next.
c.
d. In the Options dialog, click Next to accept the default options (no options are selected by default). e. In the Configuration Profile dialog, select (no profile) from the Profile drop-down list (this is the default). Click Finish.
This creates a project directory with the name, netdlink_demo. The new project appears in the Project Navigator pane on the left. 2. Configure a custom VxWorks kernel to include the appropriate networking components. a. Expand the new netdlink_demo project and right-click Kernel Configuration. Select Edit Kernel Configuration. This opens the component configuration tool in the center pane of the Application Development window. Select the Components tab at the bottom of the kernel configuration pane (if it is not already selected). Right-click in the component configuration field and select Find. Use the Find tool to locate the
b.
91
INCLUDE_ROUTECMD and INCLUDE_PING components. To find a component, type the component name (for example, INCLUDE_PING) in the Pattern field. When the component appears in the Matching list, select the component and click the Find button. This returns you to the component configuration tool. The selected component is highlighted in the component tree.
c.
Right-click the selected component and select Include (quick include).
d. Right-click in the component tree and select Save. 3. Build your project. a. Right-click on the netdlink_demo project in the Project Navigator (upper left pane) and select Build Project (this executes the make command in the project directory). The build output appears in the Build Console (lower right pane).
6.4.3 Start a Simulator Instance on Each Host

Start a VxWorks simulator instance on each host. Before launching each simulator, be sure to change to the directory where you built your VxWorks image (for example, installDir/netdlink_demo/default). On the first host, launch the VxWorks simulator instance (VxSim1) from the VxWorks Development Shell as follows:
-> vxsim -d simnet -e 192.168.200.1 -p 1
On the second host, launch the VxWorks simulator instance (VxSim2) from the VxWorks Development Shell as follows:
-> vxsim -d simnet -e 192.168.200.2 -p 2
NOTE: You can also start the VxWorks simulator instances from Workbench,
specifying the same parameters.
6.4.4 Connect the Simulated Subnets Using wrnetdlink

From the VxWorks Development Shell on the first host, launch the wrnetdlink utility using the following command:
-> wrnetdlink -net -net host2
where hostname2 is the IP address or host name of the second host. In the above command, the first -net flag (with no parameters) specifies a connection to the local host network daemon on port 5555 and connecting to the first configured subnet (in this case, the default is 192.168.200.0). The second -net flag specifies a connection to the network daemon running on host2 using the default port and connecting to the first configured subnet.
92
6 Networking Tutorials 6.5 Adding a VxWorks Simulator to a Local Network
6.4.5 Test the Simulated Network

You can now test the simulated network using the ping application. From the VxWorks simulator instance on the second host, you can ping the VxWorks simulator instance on the first host as follows:
-> ping 192.168.200.1
6.5 Adding a VxWorks Simulator to a Local Network

This tutorial demonstrates how to plug the VxWorks simulator directly into your local network through a bridge configured on your host.
6.5.1 Default Subnet Configuration

By default, vxsimnetd configures the WRTAP interface with an IP address of 192.168.200.254. In this configuration, the host machine appears as a gateway between two subnets: the local one (for example, 10.10.10.0) and the VxWorks simulator subnet (192.168.200.0). The following diagram shows a VxWorks simulator host machine and another host machine on the same local subnetwork.
VxSim host 10.10.10.2
VxSim 192.168.200.1
VxSim 192.168.200.2
VxSim subnet 192.168.200.0
Host 10.10.10.1
Local interface 10.10.10.2
IP forwarding
Tap/WRTAP interface 192.168.200.254
Local subnet 10.10.10.0
In this case, if you want to access host 10.10.10.1 from the VxWorks simulator, you must set up the following routes:
93
1.
Indicate that you can reach the 10.10.10.0 subnet through the host interface 192.168.200.254:
-> routec "add -net 10.10.10.0/24 192.168.200.254"
2.
On each remote host, indicate that host 10.10.10.2 is the gateway to reach the 192.168.200.0 network. For example, execute the following from your host command shell: For Windows hosts:
C:\> route add 192.168.200.0 mask 255.255.255.0 10.10.10.2
On Linux hosts:
% route add -net 192.168.200.0 gw 10.10.10.2
6.5.2 Configuring a Bridge

To simplify route settings, you can connect the VxWorks simulator directly to your local network through a bridgeconfigured on your host machinebetween the local network interface and the WRTAP interface. The goal of setting up such a bridge is to allow a VxWorks simulator instance started on 10.10.10.2 to ping any host on the local subnet (without having to set up additional routes). The following diagram illustrates this configuration:
VxSim host2 10.10.10.2
VxSim0 10.10.10.30
VxSim1 10.10.10.40
VxSim subnet 10.10.10.0
Host1 10.10.10.1
Local interface 10.10.10.2
Bridge
Tap/WRTAP interface 10.10.10.254
Local subnet 10.10.10.0
94
6 Networking Tutorials 6.5 Adding a VxWorks Simulator to a Local Network
Windows Hosts
To configure the bridge on a Windows host, complete the following steps: 1. Create a vxsimnetd configuration file for your local subnet (the following example assumes that your local subnet is 10.10.10.0):
SUBNET_START local_subnet { SUBNET_ADDRESS = "10.10.10.0"; SUBNET_MASK = "255.255.255.0"; SUBNET_EXTERNAL = yes; SUBNET_EXTPROMISC = no; };
2.
Start vxsimnetd using the configuration file that you created above. For more information on starting the network daemon, see 5.2.2 Setting Up the Network Daemon, p.50. Once you have started vxsimnetd, check the network interfaces in Control Panel > Network Connections. You should be able to see the WRTAP interface configured on the same subnetwork as your local network interface. For example, you would see a local interface of 10.10.10.2 and WRTAP interface of 10.10.10.254. To set up the bridge, control-click to select both interfaces then right-click and select bridge from the pop-up menu. Select the newly created bridge then right-click and select properties. Configure the bridge in the same way the local interface is configured (either DHCP or fixed address and gateway). Start a VxWorks simulator instance:
-> vxsim p 0 -d simnet -e 10.10.10.30
3.
4.
5.
You should now be able to access any other host without modifying routing tables. For example, you can ping Host1 (as shown in the figure above) from VxSim0 as follows:
-> ping "10.10.10.1"
6.
If you started vxsimnetd as a service with your local subnet configuration, the bridge should continue to be available after a reboot of your host.
Linux Hosts
The tutorial in this section must be performed locally on the host machine and not through a remote connection. Any remote connection will be temporarily disrupted during bridge set up.
NOTE: To use the VxWorks simulator on a local bridge in Linux, you must ensure
that the bridge module is installed on your Linux host. You can verify this using the modinfo bridge command. If necessary, install the package that contains this module. In addition, you will need the brctl command that is available in the bridge-utils package.
95
To configure the bridge on a Linux host, complete the following steps: 1. To make sure the bridge module is available and loaded on your Linux host, issue the following commands:
# modinfo bridge filename: /lib/modules/2.6.9-67.0.20.ELhugemem/kernel/net/bridge/bridge.ko license: GPL vermagic: 2.6.9-67.0.20.ELhugemem SMP 686 REGPARM 4KSTACKS gcc-3.4 depends: atm # modprobe bridge
2.
Once you have verified that the required modules are available, create a vxsimnetd configuration file for your local subnet (10.10.10.0 in this example):
SUBNET_START local_subnet { SUBNET_ADDRESS = "10.10.10.0"; SUBNET_MASK = "255.255.255.0"; SUBNET_EXTERNAL = yes; SUBNET_EXTPROMISC = no; SUBNET_EXTDEVNUM = 1; };
3.
Start vxsimnetd with this configuration file or source it through an existing vxsimnetd shell. From a command shell with root privileges, issue the following command:
$ vxsimnetd -f local_subnet.conf -sv
If vxsimnetd was previously started as root with a shell server, issue the following commands from a command shell:
$ cp local_subnet.conf /tmp/local_subnet.conf $ telnet localhost 7777 vxsimnet> source /tmp/local_subnet.conf subnet(s) <local_subnet> added.
4.
With root privileges, set up the bridge as follows:

$ $ $ $ $ $ brctl addbr bridge0 brctl addif bridge0 eth0 brctl addif bridge0 tap1 ifconfig tap1 0.0.0.0 ifconfig eth0 0.0.0.0 ifconfig bridge0 10.10.10.2 netmask 255.255.255.0 up
5.
From the VxWorks Development Shell, start the VxWorks simulator instance using the following command:
-> vxsim p 0 -d simnet -e 10.10.10.30
6.
Check your routes and reset if necessary:

-> netstat -r
Note that when vxsimnetd is stopped, it removes the WRTAP interface from the bridge. When vxsimnetd is restarted, you must run the following commands to install the WRTAP interface into the bridge:
$ brctl addif bridge0 tap1 $ ifconfig tap1 0.0.0.0
96
6 Networking Tutorials 6.6 IPv6 Tutorial
6.6 IPv6 Tutorial

This tutorial illustrates how to configure your host system and your target simulators to communicate using IPv6 protocol. For more information on IPv6, see the Wind River Network Stack Programmer's Guide, Volume 1: Transport and Network Protocols: Configuring Transport and Network Protocols. This tutorial describes how to:
Enable IPv6 support on your host system. Configure the VxWorks simulator network daemon. Configure a VxWorks image for use as an IPv6-enabled simulator. Start your IPv6 VxWorks simulator network and test your connections.
6.6.1 Configure the Network

This section describes how to set up your host system and the VxWorks simulator network daemon for use with an IPv6 network.
Step 1: Configure Your Host System
In order to receive IPv6 packets from the VxWorks simulator subnet, you must configure your host system with IPv6 support. On Windows hosts, configure IPv6 support by issuing the following command from a Windows command shell:
C:\> ipv6 install
On Linux hosts, issue the following command in a host shell:

$ modprobe ipv6
On Solaris hosts, IPv6 support is configured during setup. To confirm IPv6 support on your host, log in with root privileges and issue the following command in the host shell:
# ifconfig -a6
If IPv6 support is present the command will be successful. If the command is unsuccessful, see your host system documentation for information on enabling IPv6 support or consult your system administrator.
Step 2: Configure and Start the Network Daemon
This tutorial uses a network configuration that includes two subnets (default and sub3) that are configured with IPv4 addresses. The IPv4 addresses are used only to identify the subnets and to assign MAC addresses (see Starting a Simulator Instance without an IPv4 Address, p.69).
NOTE: Before launching vxsimnetd, be sure to kill all previously started VxWorks
simulator instances and then kill the previously started network daemon.
97
You can configure the VxWorks simulator network daemon (vxsimnetd) using one of the following methods:
using a static configuration file dynamically using the shell
Start vxsimnetd Using a Static Configuration File
Follow the instructions as provided in Step 1:Configure and Launch vxsimnetd, p.80 using the following file in place of the vxsimTest.conf file (save the file as ipv6_tutorial_static.conf):
SUBNET_START default { SUBNET_ADDRESS = "192.168.200.0"; SUBNET_EXTERNAL = yes; SUBNET_EXTPROMISC = yes; }; SUBNET_START sub3 { SUBNET_ADDRESS = "192.168.3.0"; SUBNET_EXTERNAL = no; };
Configure vxsimnetd Dynamically Using the Shell
You can also configure the VxWorks simulator network daemon dynamically. First, launch the vxsimnetd shell server as directed in Step 1:Launch the vxsimnetd Shell Server, p.86. Then, complete the following steps: 1. Create and save the following file as ipv6_tutorial_dynamic.conf:
SUBNET_START sub3 { SUBNET_ADDRESS = "192.168.3.0"; SUBNET_EXTERNAL = no; };
2.
Connect to the vxsimnetd shell. From your host shell, type the following:
% telnet yourHostName 7777
where yourHostName is the name of your host machine. 3. In the vxsimnetd debug shell, source the new configuration file as follows:
vxsimnetd> source /myDir/ipv6_tutorial_dynamic.conf Subnet <sub3> added.
4.
Quit the vxsimnetd shell.

vxsimnetd> quit
6.6.2 Configuring VxWorks with IPv6 Components

NOTE: Before configuring your VxWorks image, make sure that your network
stack is enabled with IPv6 support. For information on building your network stack with IPv6 support, see the Wind River Network Stack Programmer's Guide, Volume 1: Transport and Network Protocols: Configuring Transport and Network Protocols. This tutorial uses a VxWorks simulator configuration to demonstrate router advertisement and solicitation. The tutorial requires that you configure your VxWorks image with the following components:
98
INCLUDE_IPD_CMD INCLUDE_IPCOM_SYSVAR_CMD INCLUDE_IPRADVD_CMD INCLUDE_PING6
Set these components using the vxprj command-line utility using the following steps: 1. Create a project called demo_router. For example:
% vxprj -inet6 create bsp TOOL demo_router
where bsp is the BSP for your host system type (simpc, linux, or solaris) and TOOL is your desired toolchain (diab or gnu).
NOTE: Wind River VxWorks Platforms users must omit the -inet6 option (or,
when using Workbench, do not to check the Use IPv6 enabled kernel libraries option in the Options dialog of the New VxWorks Image Project wizard). Also, be sure that you have built your Platform with IPv6 support. For more information, see the Wind River Network Stack Programmer's Guide, Volume 1: Transport and Network Protocols: Configuring Transport and Network Protocols and your Platform getting started guide. 2. 3. Change to the demo_router directory:
% cd demo_router
Add the INCLUDE_IPD_CMD, INCLUDE_IPCOM_SYSVAR_CMD, INCLUDE_IPRADVD_CMD, and INCLUDE_PING6 components:

% vxprj component add INCLUDE_IPD_CMD INCLUDE_IPCOM_SYSVAR_CMD INCLUDE_IPRADVD_CMD INCLUDE_PING6
NOTE: You can also create your project and configure your VxWorks image from
Workbench using the kernel configuration tool. For more information on configuring components using Workbench, see Prepare Your VxWorks Image Using Workbench, p.82 or Wind River Workbench By Example: Configuring and Building VxWorks.
Build Your Projects
Build the demo_router project as follows:

% vxprj build
6.6.3 Testing the IPv6 Connection

This section describes how to test the IPv6 connections in your simulated network.
Start the VxWorks Simulator Instances
Before you can test the IPv6 connection, you must start your VxWorks simulator instances using the VxWorks images you created.
99
Step 1:
Start the Simulator Instances on the Default Subnet
1.
Create a startup script (default_startup) that specifies the prefix to advertise:

# switch interpreter cmd # add IPv6 address ifconfig simnet0 inet6 add 2002:A01:201::787A:C0FF:FEA8:C801 # configure advertisement radvdconfig simnet0 add test 2002:0a01:0201::/64 valid 600 preferred 200 L A radvdconfig simnet0 enable test # start advertising prefix sysvar set -o ipnet.inet6.radvd.interfaces simnet0 ipd start ipnet_radvd
2.
Start one advertiser VxWorks simulator instance on the default subnet. You can start the simulator instance from the VxWorks Development Shell using the script you just created as follows:
-> vxsim -p 0 -d simnet -e 192.168.200.1 -f installDir/demo_router/default/vxworks -s pathToStartupScript/default_startup
Where pathToStartupScript is the full path to your startup script location. This starts a VxWorks simulator instance (VxSim0) with an advertiser configuration on the default subnet. 3. Start a solicitor VxWorks simulator instance on the default subnet as follows:
-> vxsim -p 1 -d simnet -e 192.168.200.2 -f installDir/demo_router/default/vxworks
This starts a VxWorks simulator instance (VxSim1) with the solicitor configuration on the default subnet.
Step 2: Start the Simulator Instances on Subnet 3
1.
Start one advertiser and one solicitor instance on subnet 3. First, create a startup script (sub3_startup) that specifies the prefix to advertise:
# switch interpreter cmd # add IPv6 address ifconfig simnet0 inet6 add 2002:A01:202::787A:C0FF:FEA8:C801 # configure advertisement radvdconfig simnet0 add test 2002:0a01:0202::/64 valid 600 preferred 200 L A radvdconfig simnet0 enable test # start advertising prefix sysvar set -o ipnet.inet6.radvd.interfaces simnet0 ipd start ipnet_radvd
2.
Start the advertiser VxWorks simulator instance. You can start the simulator instance from the VxWorks Development Shell using the script you just created:
-> vxsim -p 2 -ni simnet0=192.168.3.1;simnet1=192.168.200.3 -f installDir/demo_router/default/vxworks -s pathToStartupScript/sub3_startup
where pathToStartupScript is the full path to your startup script location. This starts a VxWorks simulator instance (VxSim2) with the advertiser configuration on subnet 3. 3. Start the solicitor VxWorks simulator instance as follows:
-> vxsim -p 3 -d simnet -e 192.168.3.2 -f installDir/demo_router/default/vxworks
This starts a VxWorks simulator instance (VxSim3) with the solicitor configuration on subnet 3.
100
Step 3:
Check Your Connections
You can now check to see if the VxWorks simulator instances are correctly configured.
NOTE: You may need to wait 10-30 seconds for the network autoconfiguration to
complete. 1. In the VxSim0 console, type the following:

-> ifconfig "simnet0" simnet0 Link type:Ethernet HWaddr 7a:7a:c0:a8:c8:01 Queue:none inet 192.168.200.1 mask 255.255.255.0 broadcast 192.168.200.255 inet 224.0.0.1 mask 240.0.0.0 inet6 unicast 2002:A01:201::787A:C0FF:FEA8:C801 prefixlen 64 inet6 unicast FE80::787A:C0FF:FEA8:C801%simnet0 prefixlen 64 automatic inet6 unicast 3FFE:1:2:3::4 prefixlen 64 inet6 unicast FE80::%simnet0 prefixlen 64 anycast inet6 unicast 2002:A01:201:: prefixlen 64 anycast inet6 unicast 3FFE:1:2:3:: prefixlen 64 anycast inet6 multicast FF02::1:FF00:4%simnet0 prefixlen 16 inet6 multicast FF02::1:FF00:0%simnet0 prefixlen 16 inet6 multicast FF02::1%simnet0 prefixlen 16 automatic inet6 multicast FF02::1:FFA8:C801%simnet0 prefixlen 16 inet6 multicast FF02::2%simnet0 prefixlen 16 UP RUNNING SIMPLEX BROADCAST MULTICAST MTU:1500 metric:1 VR:0 RX packets:0 mcast:0 errors:0 dropped:0 TX packets:11 mcast:10 errors:0 collisions:0 unsupported proto:0 RX bytes:0 TX bytes:966 value = 0 = 0x0
2.
In the VxSim1 console, type the following:

-> ifconfig "simnet0" simnet0 Link type:Ethernet HWaddr 7a:7a:c0:a8:c8:02 Queue:none inet 192.168.200.2 mask 255.255.255.0 broadcast 192.168.200.255 inet 224.0.0.1 mask 240.0.0.0 inet6 unicast 2002:A01:201::787A:C0FF:FEA8:C802 prefixlen 64 autonomous inet6 unicast FE80::787A:C0FF:FEA8:C802%simnet0 prefixlen 64 automatic inet6 unicast 3FFE:1:2:3::4 prefixlen 64 inet6 unicast 2002:A01:201:: prefixlen 64 anycast inet6 unicast FE80::%simnet0 prefixlen 64 anycast inet6 unicast 3FFE:1:2:3:: prefixlen 64 anycast inet6 multicast FF02::1:FF00:4%simnet0 prefixlen 16 inet6 multicast FF02::1:FF00:0%simnet0 prefixlen 16 inet6 multicast FF02::1%simnet0 prefixlen 16 automatic inet6 multicast FF02::1:FFA8:C802%simnet0 prefixlen 16 UP RUNNING SIMPLEX BROADCAST MULTICAST MTU:1500 metric:1 VR:0 RX packets:3 mcast:2 errors:0 dropped:0 TX packets:9 mcast:8 errors:0 collisions:0 unsupported proto:0 RX bytes:264 TX bytes:730 value = 0 = 0x0
101
3.

-> ifconfig lo0 Link type:Local loopback Queue:none inet 127.0.0.1 mask 255.255.255.255 inet 224.0.0.1 mask 240.0.0.0 inet6 unicast FE80::1%lo0 prefixlen 64 automatic inet6 unicast ::1 prefixlen 128 inet6 multicast FF02::1:FF00:1%lo0 prefixlen 16 inet6 multicast FF01::1 prefixlen 16 inet6 multicast FF02::1%lo0 prefixlen 16 automatic UP RUNNING LOOPBACK MULTICAST MTU:1500 metric:1 VR:0 RX packets:9 mcast:0 errors:0 dropped:5 TX packets:9 mcast:3 errors:0 collisions:0 unsupported proto:0 RX bytes:440 TX bytes:440 simnet0 Link type:Ethernet HWaddr 7a:7a:c0:a8:03:01 Queue:none inet 192.168.3.1 mask 255.255.255.0 broadcast 192.168.3.255 inet 224.0.0.1 mask 240.0.0.0 inet6 unicast 2002:A01:202::787A:C0FF:FEA8:C801 prefixlen 64 inet6 unicast FE80::787A:C0FF:FEA8:301%simnet0 prefixlen 64 automatic inet6 unicast FE80::%simnet0 prefixlen 64 anycast inet6 unicast 2002:A01:202:: prefixlen 64 anycast inet6 multicast FF02::1%simnet0 prefixlen 16 automatic inet6 multicast FF02::1:FFA8:301%simnet0 prefixlen 16 inet6 multicast FF02::1:FFA8:C801%simnet0 prefixlen 16 inet6 multicast FF02::1:FF00:0%simnet0 prefixlen 16 inet6 multicast FF02::2%simnet0 prefixlen 16 UP RUNNING SIMPLEX BROADCAST MULTICAST MTU:1500 metric:1 VR:0 RX packets:2 mcast:1 errors:0 dropped:0 TX packets:11 mcast:10 errors:0 collisions:0 unsupported proto:0 RX bytes:130 TX bytes:966 simnet1 Link type:Ethernet HWaddr 7a:7a:c0:a8:c8:03 Queue:none inet 192.168.200.3 mask 255.255.255.0 broadcast 192.168.200.255 inet 224.0.0.1 mask 240.0.0.0 inet6 unicast 2002:A01:201::787A:C0FF:FEA8:C803 prefixlen 64 autonomous inet6 unicast FE80::787A:C0FF:FEA8:C803%simnet1 prefixlen 64 automatic inet6 unicast 2002:A01:201:: prefixlen 64 anycast inet6 unicast FE80::%simnet1 prefixlen 64 anycast inet6 multicast FF02::1%simnet1 prefixlen 16 automatic inet6 multicast FF02::1:FFA8:C803%simnet1 prefixlen 16 inet6 multicast FF02::1:FF00:0%simnet1 prefixlen 16 UP RUNNING SIMPLEX BROADCAST MULTICAST MTU:1500 metric:1 VR:0 RX packets:1 mcast:1 errors:0 dropped:0 TX packets:7 mcast:6 errors:0 collisions:0 unsupported proto:0 RX bytes:102 TX bytes:550 value = 0 = 0x0
102
4.

-> ifconfig "simnet0" simnet0 Link type:Ethernet HWaddr 7a:7a:c0:a8:03:02 Queue:none inet 192.168.3.2 mask 255.255.255.0 broadcast 192.168.3.255 inet 224.0.0.1 mask 240.0.0.0 inet6 unicast 2002:A01:202::787A:C0FF:FEA8:302 prefixlen 64 autonomous inet6 unicast FE80::787A:C0FF:FEA8:302%simnet0 prefixlen 64 automatic inet6 unicast 3FFE:1:2:3::4 prefixlen 64 inet6 unicast 2002:A01:202:: prefixlen 64 anycast inet6 unicast FE80::%simnet0 prefixlen 64 anycast inet6 unicast 3FFE:1:2:3:: prefixlen 64 anycast inet6 multicast FF02::1:FF00:4%simnet0 prefixlen 16 inet6 multicast FF02::1:FF00:0%simnet0 prefixlen 16 inet6 multicast FF02::1%simnet0 prefixlen 16 automatic inet6 multicast FF02::1:FFA8:302%simnet0 prefixlen 16 UP RUNNING SIMPLEX BROADCAST MULTICAST MTU:1500 metric:1 VR:0 RX packets:3 mcast:3 errors:0 dropped:0 TX packets:9 mcast:8 errors:0 collisions:0 unsupported proto:0 RX bytes:306 TX bytes:730 value = 0 = 0x0
Step 4:
Ping your Simulator Instances
You can now ping the VxWorks simulator instances on the same subnet. The default subnet (default) includes VxSim0, VxSim1, and the host system. Subnet 3 (sub3) includes VxSim2 and VxSim3. 1. Ping VxSim1 from VxSim0. In the VxSim0 console, enter the following:
-> cmd [vxWorks *]# ping6 2002:A01:201::787A:C0FF:FEA8:C802 Pinging 2002:A01:201::787A:C0FF:FEA8:C802 (2002:A01:201::787A:C0FF:FEA8:C802) with 64 bytes of data: Reply from 2002:A01:201::787A:C0FF:FEA8:C802 bytes=64 time=0ms Reply from 2002:A01:201::787A:C0FF:FEA8:C802 bytes=64 time=0ms Reply from 2002:A01:201::787A:C0FF:FEA8:C802 bytes=64 time=0ms Reply from 2002:A01:201::787A:C0FF:FEA8:C802 bytes=64 time=0ms
hlim=64 hlim=64 hlim=64 hlim=64
--- 2002:A01:201::787A:C0FF:FEA8:C802 ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 4066 ms rtt min/avg/max = 0/0/0 ms
2.
In the VxSim1 console, you can ping VxSim0 with the local address as follows:
-> cmd [vxWorks *]# ping6 FE80::787A:C0FF:FEA8:C801%simnet0 Pinging FE80::787A:C0FF:FEA8:C801%simnet0 (FE80::787A:C0FF:FEA8:C801%simnet0) with 64 bytes of data: Reply from FE80::787A:C0FF:FEA8:C801%simnet0 bytes=64 time=0ms Reply from FE80::787A:C0FF:FEA8:C801%simnet0 bytes=64 time=0ms Reply from FE80::787A:C0FF:FEA8:C801%simnet0 bytes=64 time=0ms Reply from FE80::787A:C0FF:FEA8:C801%simnet0 bytes=64 time=0ms
--- FE80::787A:C0FF:FEA8:C801%simnet0 ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 4066 ms rtt min/avg/max = 0/0/0 ms
103
3.
From VxSim1, you can also ping VxSim0 at the automatically configured address as follows:
-> cmd [vxWorks *]# ping6 2002:A01:201::787A:c0FF:FEA8:C801 Pinging 2002:A01:201::787A:C0FF:FEA8:C801 (2002:A01:201::787A:C0FF:FEA8:C801) with 64 bytes of data: Reply from 2002:A01:201::787A:C0FF:FEA8:C801 bytes=64 time=0ms Reply from 2002:A01:201::787A:C0FF:FEA8:C801 bytes=64 time=0ms Reply from 2002:A01:201::787A:C0FF:FEA8:C801 bytes=64 time=0ms Reply from 2002:A01:201::787A:C0FF:FEA8:C801 bytes=64 time=0ms
--- 2002:A01:201::787A:C0FF:FEA8:C801 ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 4066 ms rtt min/avg/max = 0/0/0 ms
4.
From VxSim0 or VxSim1, you can also ping the host:

-> cmd [vxWorks *]# ping6 2002:A01:201::787A:C0FF:FEA8:C8FE Pinging 2002:A01:201::787A:C0FF:FEA8:C8FE (2002:A01:201::787A:C0FF:FEA8:C8FE) with 64 bytes of data: Reply from 2002:A01:201::787A:C0FF:FEA8:C8FE bytes=64 time=16ms hlim=64 Reply from 2002:A01:201::787A:C0FF:FEA8:C8FE bytes=64 time=0ms hlim=64 Reply from 2002:A01:201::787A:C0FF:FEA8:C8FE bytes=64 time=0ms hlim=64 Reply from 2002:A01:201::787A:C0FF:FEA8:C8FE bytes=64 time=0ms hlim=64 --- 2002:A01:201::787A:C0FF:FEA8:C8FE ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 4067 ms rtt min/avg/max = 0/4/16 ms
In addition, you can set the routing such that you can ping between the default subnet and subnet 3 through VxSim2. For an example of how to set up the routing information, see the tutorials in 6.3 Basic Simulated Network with Multiple Simulators, p.79.
104
7
Tutorial: Simulating VxWorks AMP
7.1 Introduction 105 7.2 Tutorial: Simulating AMP 105
7.1 Introduction
VxWorks supports asynchronous multi-processing (AMP) on multicore processorsVxWorks AMP (see VxWorks Kernel Programmers Guide: Overview of VxWorks AMP). This makes it possible for independent instances of the VxWorks operating system to run on the individual CPUs of a multicore processor. You can simulate VxWorks AMP by using a separate instance of the VxWorks simulator for each AMP CPU. This chapter presents a tutorial on how to build and configure instances of the VxWorks simulator for VxWorks AMP. Once you have a simulated VxWorks AMP configuration, you can use it to develop VxWorks AMP applications. This may be useful if your target hardware is still under development.
7.2 Tutorial: Simulating AMP

You cannot simulate symmetric multiprocessing (SMP) at the same time that you simulate AMP. Given this, when you configure VxWorks AMP on a multicore processor, CPU 0 is the primary CPU, and all other CPUs are considered secondary CPUs. The primary CPU always boots first and is then used to boot the secondary CPUs. To make this possible, the build requirements for the primary CPU are slightly different than the requirements for secondary CPUs. This tutorial shows you how to use the VxWorks simulator to simulate a VxWorks AMP configuration consisting of a primary CPU and three secondary CPUs.
105
The basic steps in simulating VxWorks AMP are: 1. 2. 3. 4. Create and Build a VxWorks Image Project for Simulating the Primary CPU, p.106. Create and Build VxWorks Image Projects for Simulating Secondary CPUs, p.109. Start the VxWorks Simulation of the Primary CPU, p.112. Start the VxWorks Simulation of a Secondary CPU, p.112.
7.2.1 Create and Build a VxWorks Image Project for Simulating the Primary CPU
You can create and build your VxWorks image project from either Workbench or the command line.
Workbench
In Workbench, you can locate any of the build components and parameters mentioned in this chapter by right-clicking anywhere in the Kernel Configuration Editor and selecting the Find tool. To create and build an image project for simulating a primary CPU using Workbench: 1. For the following steps, make sure that the Workbench Advanced Device Development perspective is displayed. The title bar at the upper left of the Workbench window shows the current perspective. To display the Advanced Device Development perspective, select Window > Open Perspective > Advanced Device Development. 2. Create a new VxWorks image project. a. b. Select File > New > VxWorks Image Project. This launches the New VxWorks Image Project wizard. In the Project name field of the Project dialog, enter a name for your project. For the current example, the project name is sim_primary. Click Next. In the Project Setup dialog, choose to base your project on a board support package and select or confirm your board support package and toolchain. The appropriate BSP for the VxWorks simulator is simpc on Windows hosts, linux on Linux hosts, or solaris on Solaris hosts. The toolchain can be either diab (Wind River Diab Compiler) or gnu (GNU compiler). Click Finish.
c.
3.
Add the required MIPC components to your kernel configuration. a. In the Workbench Project Explorer, expand the sim_primary project you created (if it is not already expanded), right-click Kernel Configuration, and select Edit Kernel Configuration.
106
7 Tutorial: Simulating VxWorks AMP 7.2 Tutorial: Simulating AMP
b.
Select the Bundles tab. Locate the AMP Primary OS (BUNDLE_AMP_PRI) bundle, right-click it, and select Add. The Bundles tab is at the bottom left of the Kernel Configuration Editor, when the Editor is at its default size. (If you enlarge the Kernel Configuration display by double-clicking the project tab at the top, the Bundles tab at the bottom may not be visible.) The BUNDLE_AMP_PRI bundle adds the following components for AMP to your project: MIPC over SM (INCLUDE_MIPC_SM) Multi-Os IPC serial device (INCLUDE_MSD) MIPC WDB Agent Proxy backend (INCLUDE_WDB_PROXY_MIPC) WRLoad (INCLUDE_WRLOAD)
4.
Set the Maximum nodes per bus (MIPC_SM_NODES) parameter to 4. This parameter is contained in the MIPC over SM (INCLUDE_MIPC_SM) build component.
5.
Set the Number of MSD devices (MSD_NUM_DEVS) parameter to 3. This parameter is contained in the MIPC over SM (INCLUDE_MIPC_SM) build component.
6.
To include show routines for AMP and a demo application for AMP and MIPC, add the following components: MIPC demo (INCLUDE_MIPC_DEMO) MIPC Show routines (INCLUDE_MIPC_SHOW) For information on these components, see Wind River MIPC Programmers Guide: Building and Configuring MIPC for VxWorks
7.
Include the tip utility, which is used with the demo application (see Step 6), by adding the following component: tip serial line connection utility (INCLUDE_TIP) In an AMP environment, the tip utility allows you to establish a terminal connection to one or more CPUs on a target system and:
Send commands to individual CPUs that are connected through tip. Display output from CPUs located on the target system.
For more information on the tip utility, see the VxWorks Kernel Programmers Guide: The VxWorks tip Utility. 8. For the tip utility, set the Tip global configuration string (TIP_CONFIG_STRING) parameter as follows: CPU1#dev=/ttyMsd0#tag=CPU1|CPU2#dev=/ttyMsd1#tag=CPU2|CP U3#dev=/ttyMsd2#tag=CPU3 9. (Optional) Add MIPC Network Device (MND) by adding the following component: MIPC Network Device (INCLUDE_MND) MND makes it possible to simulate Ethernet connections between nodes on a multicore processor and then communicate between nodes using IPv4 or IPv6 protocols or TIPC.
107
For more information on MND, see the VxWorks Kernel Programmers Guide: MND: Simulating an Ethernet Connection Between Nodes. 10. 11. For testing purposes, include the Ping client (INCLUDE_PING) build component. Build your project: right-click the project in the Project Explorer and select Build Project.
Command Line
Follow the steps below to create and build an image project for simulating the primary CPU from the command line. 1. From a VxWorks Development Shell, create a VxWorks image project using the following command:
% vxprj create bsp toolchain project_name
In the command sequence above:
bsp is the BSP name for your simulator (simpc for Windows hosts, linux for Linux hosts, or solaris for Solaris hosts) toolchain is your desired toolchain (diab for the Wind River Diab Compiler or gnu for the GNU compiler) project_name is the name of your project. For the current example, the project name is sim_primary.
2.
Change directories to the project directory and add the bundle containing components for an AMP primary CPU as follows:
% cd sim_primary % vxprj bundle add BUNDLE_AMP_PRI
The bundle includes the following components for AMP:

INCLUDE_MIPC_SM INCLUDE_MSD INCLUDE_WDB_PROXY_MIPC INCLUDE_WRLOAD
3.
Set the Maximum nodes per bus (MIPC_SM_NODES) parameter as follows:

% vxprj parameter set MIPC_SM_NODES 4
This parameter is contained in the MIPC over SM (INCLUDE_MIPC_SM) build component. 4. To include show routines for AMP and a demo application for AMP and MIPC, add the following components:
% vxprj component add INCLUDE_MIPC_SHOW INCLUDE_MIPC_DEMO
108
5.
Include the tip utility, which is used with the demo application (see Step 4), by adding the component for tip, as follows:
% vxprj component add INCLUDE_TIP
In an AMP environment, the tip utility allows you to establish a terminal connection to one or more CPUs on a target system and:
Send commands to individual CPUs that are connected through tip. Display output from CPUs located on the target system.
For more information on the tip utility, see the VxWorks Kernel Programmers Guide: The VxWorks tip Utility. 6. For the tip utility, set the Tip global configuration string (TIP_CONFIG_STRING) parameter as follows:
CPU1#dev=/ttyMsd0#tag=CPU1|CPU2#dev=/ttyMsd1#tag=CPU2|CPU3#dev=/ttyMsd2#tag=CPU3
7.
(Optional) Add MIPC Network Device (MND) by adding the component for MND, as follows:
% vxprj component add INCLUDE_MND
MND makes it possible to simulate Ethernet connections between nodes on a multicore processor and then communicate between nodes using IPv4 or IPv6 protocols or TIPC. For more information on MND, see the VxWorks Kernel Programmers Guide: MND: Simulating an Ethernet Connection Between Nodes. 8. 9. For testing purposes, include the INCLUDE_PING component in your build:
% vxprj component add INCLUDE_PING
Build your project by entering the following from the project directory:
% vxprj build
This builds a VxWorks image in the /default subdirectory. For example, installDir/workspace/sim_primary/default/vxWorks.
7.2.2 Create and Build VxWorks Image Projects for Simulating Secondary CPUs
For the current example, you only need to create and build a single VxWorks image project for a secondary CPU. All three secondary CPUs can use the same image. Most of the steps for creating and building an image project for simulating a secondary CPU are the same as those for a primary CPU.
Workbench
To create and build an image project for simulating a secondary CPU using Workbench: 1. Create a new VxWorks image project as described for the primary CPU (see Step 1 for Workbench under 7.2.1 Create and Build a VxWorks Image Project for Simulating the Primary CPU, p.106).
109
2.
Add the required MIPC components to your kernel configuration: a. In the Workbench Project Explorer, expand the project you created for a secondary CPU (if it is not already expanded), right-click Kernel Configuration, and select Edit Kernel Configuration. Select the Bundles tab. Locate the AMP Secondary OS (BUNDLE_AMP_SEC) bundle, right-click on it, and select Add. The Bundles tab is at the bottom left of the Kernel Configuration Editor, when the Editor is at its default size. (If you enlarge the Kernel Configuration display by double-clicking the project tab at the top, the Bundles tab at the bottom may not be visible.) The bundle adds the following components for AMP to your project: MIPC over SM (INCLUDE_MIPC_SM) Multi-Os IPC serial device (INCLUDE_MSD) WDB MIPC connection (INCLUDE_WDB_COMM_MIPC) WRLoad image build (INCLUDE_WRLOAD_IMAGE_BUILD)
b.
3.
Set the Maximum nodes per bus (MIPC_SM_NODES) parameter to 4. This parameter is contained in the MIPC over SM (INCLUDE_MIPC_SM) build component.
4. 5.
Remove the (INCLUDE_WDB_SYS) build component from your project. To include show routines for AMP and a demo application for AMP and MIPC, add the following components: MIPC demo (INCLUDE_MIPC_DEMO) MIPC Show routines (INCLUDE_MIPC_SHOW) For information on these components, see Wind River MIPC Programmers Guide: Building and Configuring MIPC for VxWorks
6.
(Optional) Add MIPC Network Device (MND; see the description at Step 9 for the primary CPU) by adding the following component: MIPC Network Device (INCLUDE_MND) Note that the tip utility, which is included for primary CPUs, does not get included for secondary CPUs.
7. 8.
For testing purposes, include the Ping client (INCLUDE_PING) build component. Build your project: right-click the project in the Project Explorer and select Build Project.
Command Line
To create and build an image project for simulating a secondary CPU from the command line: 1. From a VxWorks Development Shell, create a VxWorks image project as described in Step 2 for Command Line under Create and Build a VxWorks Image Project for Simulating the Primary CPU.
% vxprj create bsp toolchain project_name
110
In the command sequence above:
bsp is the BSP name for your simulator (simpc for Windows hosts, linux for Linux hosts, or solaris for Solaris hosts) toolchain is your desired toolchain (diab for the Wind River Diab Compiler or gnu for the GNU compiler) project_name is the name of your project. For the current example, the project name is sim_secondary.
2.
Change directories to the project directory and add the bundle containing components for an AMP secondary CPU as follows:
% cd sim_secondary % vxprj bundle add BUNDLE_AMP_SEC
The bundle contains the following components for AMP:

INCLUDE_MIPC_SM INCLUDE_MSD INCLUDE_WDB_COMM_MIPC INCLUDE_WRLOAD_IMAGE_BUILD
3.
Set the MIPC_SM_NODES parameter as follows:

% vxprj parameter set MIPC_SM_NODES 4
This parameter is contained in the MIPC over SM (INCLUDE_MIPC_SM) build component. 4. 5. Remove the INCLUDE_WDB_SYS build component from your project:
% vxprj component remove INCLUDE_WDB_SYS
To include show routines for AMP and a demo application for AMP and MIPC, add the following components:
% vxprj component add INCLUDE_MCB_SHOW INCLUDE_MIPC_DEMO
For information on these components, see Wind River MIPC Programmers Guide: Building and Configuring MIPC for VxWorks 6. (Optional) To include MIPC Network Device (MND; see the description at Step 9 for the primary CPU), add the following component: MIPC Network Device (INCLUDE_MND) Note that the tip utility, which is included for primary CPUs, does not get included for secondary CPUs. 7. 8. For testing purposes, include the INCLUDE_PING component in your build:
% vxprj component add INCLUDE_PING
Build your project by entering the following from the project directory:
% vxprj build
This builds a VxWorks image in the /default subdirectory. For example, installDir/workspace/sim_secondary/default/vxWorks.
111
7.2.3 Start the VxWorks Simulation of the Primary CPU

You can start the VxWorks simulation of the primary CPU from either Workbench or the command line.
Workbench
To launch the VxWorks simulator for the primary CPU from Workbench: 1. Select Target > New Connection... This brings up the Select Remote Connection Type dialog. 2. Select Wind River VxWorks 6.x Simulator Connection and click Next. This brings up the VxWorks Boot parameters dialog. 3. In the VxWorks Boot Parameters dialog, click to the left of Custom simulator, then click Browse and navigate to the VxWorks image under the sim_primary project directory that you just created. For example: installDir/workspace/sim_primary/default/vxWorks 4. 5. Select the image, vxWorks, and click Open. In the VxWorks Boot Parameters dialog, Set Processor number to 0 which, in this case, counts as CPU 0, and click Finish. This launches the simulator instance for the primary CPU as vxsim0.
Command Line
To start the VxWorks simulator for the primary CPU from Workbench: 1. Change directories to the default directory under the sim_primary project directory that you just created. For example, change directories to:
installDir/workspace/sim_primary/default
2.
Enter the following command for processor 0, which in this case, counts as CPU 0.
% vxsim -p 0
This launches the simulator instance for the primary CPU as vxsim0.
7.2.4 Start the VxWorks Simulation of a Secondary CPU

To start the VxWorks simulation of a secondary CPU, you need to use the wrload utility (For information on wrload, see VxWorks Kernel Programmers Guide: Booting VxWorks for AMP and the wrload( ) API reference page).
To start the VxWorks simulation of a secondary CPU without specifying boot line parameters for networking, enter the following:
% wrload "-f path_to_VxWorks_image -cpu n"
112
For example:
% wrload "-f installDir/workspace/sim_secondary/default/ vxWorks -cpu 1"
This launches the simulator instance for the secondary CPU as vxsim1.
To start the VxWorks simulation of a secondary CPU with the inclusion of boot line parameters for networking, enter the following:
% wrload "-f path_to_VxWorks_image -cpu n -tsym \"*sysBootLine=network_device path_to_VxWorks_image\""
For example:
% wrload "-f VxWorks_path_to_workspace/workspace/sim_secondary/ default/vxWorks -cpu 1 -tsym \"*sysBootLine=passDev(0,1) host:workspace/sim_secondary/default/vxWorks\""
This launches the simulator instance for the secondary CPU as vxsim1. Note that the quotes around *sysBootLine and the parameters that follow it are inside a quoted string and must be escaped with a backslash (\). The following is sample output for wrload:
host:<...>/sim_secondary/default/vxWorks\"" Loading... 0x60010000 - 0x60184cd3 loaded 0x60184cd4 - 0x60184cdf zeroed 0x60186000 - 0x60194eef loaded 0x60194ef0 - 0x601bd12f zeroed Attempting string write of *sysBootLine (0x60000700) to "passDev(0,0) host:<...>/sim_secondary/default/vxWorks": OK value = 0 = 0x0
7.2.5 Verifying Connectivity Using the mipcShowBus Command

You can now use the mipcShowBus command to verify that the VxWorks simulations for primary and secondary CPUs can communicate with each other. To do this, from any of the VxWorks simulations (for example, VxSim0 or VxSim1), enter the following:
-> mipcShowBus
This command displays the nodes (CPUs, in the present context) that are currently present on bus 0 and can, therefore, communicate with each other. The following is sample output:
MIPC-SM BUS 0 { bus name: "main" maximum nodes: 4 my node number: 0 active nodes: { 0, 1, 2, 3 } statistics mode: local buffer messages: sent=0 received=6 buffer bytes: sent=0 received=4620 buffer tracking: allocated=0 freed=6 buffer not available: blocking=0 non-blocking=0 buffer available events: sent=0 received=0 express messages: sent=0 received=0 event exceptions: unavailable=0 interrupts: sent=0 received=3 deferred=3 socket usage: bound=1 closed=0 socket exceptions: rx queue full=0 }
113
Running mipcShowBus from the tip Utility
You can also verify that the tip utility is active and that connectivity to nodes through tip is working by issuing the mipcShowBus command from the tip console, as follows:
->-> tip "CPU1" Connected to CPU1 - /ttyMsd0. Press ~? for the list of available commands. [Now listening to session 1 (CPU1 - /ttyMsd0)] [Input wired to session 1 (CPU1 - /ttyMsd0)] CPU1Target Name: vxTarget CPU1User: target ... CPU1-> mipcShowBus CPU1 CPU1MIPC-SM BUS 0 CPU1{ CPU1 bus name: "main" CPU1 maximum nodes: 4 CPU1 my node number: 1 CPU1 active nodes: { 0, 1, 2, 3 } CPU1 CPU1 statistics mode: local CPU1 buffer messages: sent=0 received=15 CPU1 buffer bytes: sent=0 received=75 CPU1 buffer tracking: allocated=16 freed=14 CPU1 buffer not available: blocking=0 non-blocking=0 CPU1 buffer available events: sent=0 received=0 CPU1 express messages: sent=0 received=0 CPU1 event exceptions: unavailable=0 CPU1 interrupts: sent=15 received=15 deferred=15 CPU1 socket usage: bound=2 closed=0 CPU1 socket exceptions: rx queue full=0 CPU1}
7.2.6 Run the MIPC Demo Application

Once you have verified that your VxWorks simulators can communicate with each other, you can further test communication by running the MIPC demo application. The application allows you to send packets between two CPUs and prints out messages about the operations being performed during transmission. For more information on the MIPC demo application, see Wind River MIPC Programmers Guide: MIPC Demo.
7.2.7 Configure MND Devices and Confirm Connectivity

To simulate AMP with the use of MND devices, you need to configure MND interfaces on two or more CPUs. To configure MND devices and check connectivity, perform the following steps: 1. 2. Configure an MND interface on CPU0, as in the following example:
-> ifconfig "mnd0 inet 10.0.0.1 up"
Use the tip utility to establish a terminal connection to another CPU and configure an interface on it, as in the following example:
-> tip "CPU1" CPU1-> ifconfig "mnd0 inet 10.0.0.2 up"
114
3.
Test the connectivity between the two CPUs:

CPU1-> ping "10.0.0.1"
For more detailed information on configuring MND devices, see VxWorks Kernel Programmers Guide: MND: Simulating an Ethernet Connection Between Nodes.
115
116
A
Accessing Host Resources
A.1 Introduction 117 A.2 Accessing Host OS Routines 118 A.3 Loading a Host-Based Application 118 A.4 Host Application Interface (vxsimapi) 118 A.5 Tutorials and Examples 120
A.1 Introduction
The VxWorks simulator provides support to access the underlying host OS routines from a VxWorks application and to call host code stored in a dynamic-link library (DLL). That is, you can write a generic DLL (on any host) to control a hardware device connected to the host. The DLL can then be loaded by, and accessed through, the VxWorks simulator. For information on the available host access routines, see the reference entry for vxsimHostArchLib. vxsimHostArchLib also provides a host library (vxsimapi) for VxWorks simulator host application development. For more information, see the reference entry for vxsimapi.
117
A.2 Accessing Host OS Routines

The vxsimHostProcAddrGet( ) routine allows you to retrieve the address of a host routine. For example, the following code retrieves the address of the underlying host OS malloc( ) routine:
/* Get underlying host OS malloc() address */ pHostMalloc = vxsimHostProcAddrGet ("malloc"); /* Allocate a buffer on host side of VxWorks Simulator */ lvl = intLock (); /* lock interrupts */ pHostBuf = (*pHostMalloc) (0x1000); intUnlock (lvl); /* unlock interrupts */
You should observe the following guidelines when making a call to host code:
When you call a host routine from VxWorks code, you must always lock interrupts before calling the routine. Failure to do so can result in unexpected VxWorks simulator behavior. When you call a host routine and the routine is system blocking, the routines will not only block the VxWorks task from which it was called, but will also block the entire VxWorks simulator. To avoid blocking on a Windows simulator, create a specific thread that is responsible for calling the potentially blocking host code and set up a simple communication mechanism between VxWorks and the thread you have created. For an example of this, see A.5.2 Controlling a Host Serial Device, p.122. The method described for Windows simulators cannot be used on Linux or Solaris simulators because these simulators do not support multithreading. On these hosts, if the blocking system call is a device access, the solution is to configure the host device to generate an interrupt when data becomes available. For more information on using this method, see A.4.2 Configuring a Host Device to Generate interrupts (UNIX Only), p.119.
A.3 Loading a Host-Based Application

The vxsimHostDllLoad( ) routine provides the ability to load a DLL in the VxWorks simulator process. The exported symbols of the DLL can then be retrieved using the vxsimHostProcAddrGet( ) routine described in A.2 Accessing Host OS Routines, p.118.
A.4 Host Application Interface (vxsimapi)

The vxsimapi library provides the ability to extend VxWorks simulator capabilities with native OS code to perform operations that cannot be done directly using VxWorks code. For example, this facility can be used to add code to control
118
A Accessing Host Resources A.4 Host Application Interface (vxsimapi)
peripherals connected to the host machine, to add code for graphic applications, or to add any functionality that requires host-specific code. For more information, see the reference entry for vxsimapi.
A.4.1 Defining User Exit Hooks

Applications often need to perform specific actions on exit. This includes items such as releasing resources, re-initializing peripherals, and other cleanup operations. The VxWorks simulator exit hook facility provides the vxsimExitHookAdd( ) routine. This routine gives you the ability to specify a routine to perform any necessary cleanup when the VxWorks simulator exits or reboots.
A.4.2 Configuring a Host Device to Generate interrupts (UNIX Only)

You can put the host file descriptors in asynchronous mode, such that VxWorks sends a SIGPOLL signal is sent to the VxWorks simulator when data becomes available. If a VxWorks task reads from a host device, the task normally requires a blocking read. Because Linux and Solaris simulators are mono-threaded, this action stops the VxWorks simulator process entirely until data is ready. As an alternative, you can open the file in non-blocking mode and then put the device into asynchronous mode. This causes a SIGPOLL signal to be sent whenever data becomes available. In this case, an input ISR reads the data, puts it in a buffer, and unblocks the waiting task. To install an ISR that runs whenever data is ready on some underlying host device, you must first open the host device in non-blocking mode. Then, put the file descriptor in asynchronous mode using the vxsimFdIntEnable( ) routine. This ensures that the host will send a SIGPOLL signal when data is available. On the target side, an interrupt service routine (ISR) is connected using intConnect( ). The following code example shows how to do this on a host serial port. Host side (DLL code linked with the vxsimapi library):
/* open host device in non-blocking mode */ fd = open ("/dev/ttyb", O_NONBLOCK); /* Enable interrupts on file descriptor */ vxsimFdIntEnable (fd);
Target side:
/* connect the interrupt service routine */ intConnect (FD_TO_IVEC (fd), ISRfunc, 0);
Interrupts can also be disabled using vxsimFdIntDisable( ), and the ISR can be disconnected using intDisconnect( ). For example: Host side (DLL code linked with the vxsimapi library):
/* Disable interrupts on file descriptor */ vxsimFdIntDisable (fd);
Target side:
/* disconnect the interrupt service routine from file descriptor */ intDisconnect (FD_TO_IVEC (fd), ISRfunc, 0);
119
A.4.3 Simulating interrupts From a User Application (Windows Only)

The vxsimIntRaise( ) routine provides a host side application with the ability to notify VxWorks of a given event, allowing VxWorks to take the appropriate action. For example, if you have an application collecting data from a device, you can raise an interrupt to VxWorks when data has been read from the device. On the target side of the application, an ISR can be connected to the interrupt vector using intConnect( ). Now, each time vxsimIntRaise( ) is called, the ISR is called to handle the read data. When an interrupt needs to be acknowledged, the vxsimIntAckRtnAdd( ) routine can be used to connect an acknowledgement routine for a given interrupt vector. This routine is called immediately after the interrupt handling. A range of interrupt vectors are available on Windows simulators. This range is defined in the config.h file of the simpc BSP:
USER_INT_RANGE_BASE USER_INT_RANGE_END
User interrupts range base User interrupts range end
The routines vxsimIntToMsg( ) and vxsimMsgToInt( ) allow you to convert an interrupt vector number to a Windows message number, and conversely, allow you to convert a message number to a vector number. The vxsimWindowsHandleGet( ) routine can be used with the VxWorks simulator to get a windows handle for sending messages. For more information on Windows simulator interrupt assignments, see Table 3-4 in 3.5.5 Interrupts, p.25.
A.5 Tutorials and Examples

The following sections provide simple tutorials and examples illustrating host resource accessing.
A.5.1 Running Tcl on the VxWorks Simulator

This section provides a simple tutorial that illustrates how to load a standard Tcl DLL on the VxWorks simulator, and start a Tcl interpreter.
120
A Accessing Host Resources A.5 Tutorials and Examples
Code Sample
The following code sample can be built as a downloadable kernel module for all simulator types.
#include "vxWorks.h" #include "vxsimHostLib.h" #if (CPU==SIMNT) #define TCL_DLL "tcl84.dll" #else #define TCL_DLL "libtcl8.4.so" #endif BOOL tclLoaded = FALSE; STATUS tclStart (void) { /* Function pointers for Tcl Dll routines */ FUNCPTR FUNCPTR FUNCPTR FUNCPTR FUNCPTR char int int void * pTcl_CreateInterp; pTcl_Init; pTcl_Eval; pTcl_GetStringResult; pTcl_DeleteInterp; tclCommand[400]; evalResult; lvl; pInterp; /* /* /* /* buffer for Tcl command */ Tcl command evaluation result */ interrupt lock level */ Tcl interpreter Id */
/* Windows Tcl Dll name */ /* UNIX Tcl Dll name */
/* load Tcl Dll */ if (tclLoaded == FALSE) { if (vxsimHostDllLoad (TCL_DLL) != OK) { printf ("Error: Failed to load %s\n", TCL_DLL); return (ERROR); } tclLoaded = TRUE; } /* retrieve some Tcl routine address from the loaded Dll */ pTcl_CreateInterp pTcl_Init pTcl_Eval pTcl_GetStringResult pTcl_DeleteInterp = = = = = vxsimHostProcAddrGet vxsimHostProcAddrGet vxsimHostProcAddrGet vxsimHostProcAddrGet vxsimHostProcAddrGet ("Tcl_CreateInterp"); ("Tcl_Init"); ("Tcl_Eval"); ("Tcl_GetStringResult"); ("Tcl_DeleteInterp");
/* Create and Initialize Tcl interpreter */ lvl = intLock (); pInterp = (void *)(*pTcl_CreateInterp) (); (*pTcl_Init) (pInterp); intUnlock (lvl); /* /* /* /* lock interrupts */ Create interpreter */ Initialize interpreter */ unlock interrupts */
printf ("Tcl Ready (Type CTRL+D to exit interpreter)\n\ntcl> "); while (gets (tclCommand) != NULL) { lvl = intLock (); /* lock interrupts */ evalResult = (*pTcl_Eval) (pInterp, tclCommand); if (evalResult != 0) { printf ("Tcl Error: "); }
121
if (strlen ((*pTcl_GetStringResult)(pInterp)) != 0) printf ("%s\n", (*pTcl_GetStringResult)(pInterp)); intUnlock (lvl); printf ("tcl> "); } /* Delete Tcl interpreter */ lvl = intLock (); /* lock interrupts */ (*pTcl_DeleteInterp) (pInterp); intUnlock (lvl); /* unlock interrupts */ return (OK); } /* unlock interrupts */
Running The Code
The sample code can be executed directly from the VxWorks kernel shell or using the host shell. A sample host shell session is as follows:
-> ld < tclInterp.o value = 1634769168 = 0x61709910 -> tclStart Loading libtcl8.4.so ... succeeded. Tcl Ready (Type CTRL+D to exit interpreter) tcl> glob * tclInterp.c tclInterp.o hello.tcl tcl> source hello.tcl Hello ! tcl> ^Dvalue = 0 = 0x0 ->
A.5.2 Controlling a Host Serial Device

Controlling a host serial device is a more complex application. For an example of this application type, see the reference entry for commSio (Windows simulators) or ttySio (Linux or Solaris simulators). The examples provided for commSio and ttySio exercise most of the features described in this chapter.
122
B
VxWorks Simulator Exceptions
B.1 Introduction 123 B.2 Simulator Exceptions for Windows 123 B.3 Simulator Exceptions for UNIX-Based Operating Systems 124
B.1 Introduction
The VxWorks simulator generates separate sets of exceptions for Windows (SIMNT; see B.2 Simulator Exceptions for Windows, p.123) and UNIX-based (SIMLINUX and SIMSPARCSOLARIS; see B.3 Simulator Exceptions for UNIX-Based Operating Systems, p.124) operating systems. In both cases, the VxWorks simulator name for an exception has a corresponding POSIX name.
B.2 Simulator Exceptions for Windows

Table B-1 lists exceptions generated for the Windows operating system.
Table B-1 Windows VxWorks Simulator Exceptions
VxWorks Software Signal
POSIX Software Signal
Simulator Exception Name
Description
SIGFPE SIGEMT SIGSEGV SIGEMT SIGSEGV
SIGFPE SIGTRAP SIGBUS SIGTRAP SIGSEGV
EXC_INT_DIVIDE_BY_ZERO EXC_SINGLE_STEP EXC_DATATYPE_MISALIGNMENT EXC_BREAKPOINT EXC_IN_PAGE_ERROR
Divide by zero Single step Datatype misalignment Breakpoint In page error
123
Table B-1
Windows VxWorks Simulator Exceptions (contd)
Description
SIGILL SIGILL SIGBUS SIGILL
SIGILL SIGILL SIGSEGV SIGFPE
EXC_ILLEGAL_INSTRUCTION EXC_INVALID_DISPOSITION EXC_ARRAY_BOUNDS_EXCEEDED EXC_FLT_DENORMAL_OPERAND
Illegal instruction Invalid disposition Array bounds exceeded Floating point denormal operand Floating point divide By Zero Floating point inexact result Floating point invalid operation Floating point overflow Access violation Floating point stack check Floating point underflow Integer overflow Private instruction Stack overflow Unknown exception
SIGFPE SIGFPE SIGFPE
SIGFPE SIGFPE SIGFPE
EXC_FLT_DIVIDE_BY_ZERO EXC_FLT_INEXACT_RESULT EXC_FLT_INVALID_OPERATION
SIGFPE SIGSEGV SIGBUS SIGFPE SIGFPE SIGILL SIGBUS SIGILL
SIGFPE SIGSEGV SIGBUS SIGFPE SIGFPE SIGILL SIGBUS SIGILL
EXC_FLT_OVERFLOW EXC_ACCESS_VIOLATION EXC_FLT_STACK_CHECK EXC_FLT_UNDERFLOW EXC_INT_OVERFLOW EXC_PRIV_INSTRUCTION EXC_STACK_OVERFLOW EXC_UNKNOWN
B.3 Simulator Exceptions for UNIX-Based Operating Systems

Table B-2 lists exceptions generated for UNIX-based operating systems.
Table B-2 UNIX VxWorks Simulator Exceptions
Description
SIGSEGV SIGBUS SIGILL SIGFPE SIGTRAP
SIGSEGV SIGBUS SIGILL SIGFPE SIGTRAP
V_SEGV IV_BUS IV_ILL IV_FPE IV_TRAP
Segmentation violation BUS error Illegation instruction Floating-point exception Trap exception
124
Index
A
accessing host OS routines 118 the VxWorks Simulator from a remote host -add_dev 9, 45 -add_nat_redir 9 syntax 72 AMP tutorial 105 AMP Primary OS (bundle) 107 AMP Secondary OS (bundle) 110 -anr 9 application compatibility 2, 45 assigning a processor number 13 AUX_CLK_RATE_MAX 39 AUX_CLK_RATE_MIN 39 auxiliary clock 39 auxiliary clock interrupts 25, 27 15
BUNDLE_AMP_PRI 107, 108, 111 BUNDLE_AMP_SEC 110 byte order 24
C
C++ modules 19 commSio 122 compiler options 18 -g 20 -O 21 -O0 21 -Xno-optimized-debug 21 -XO 21 config.h 18, 34 configuring a simulated subnet 68 IPv6 support on the host 97 multiple external subnets 63 multiple network interfaces 13 VxWorks with IPv6 components 98 connecting simulated subnets with wrnetdlink 69, 92 connection timeout 23 console SMP 43 uniprocessor 12 CPU 18
B
-b 7, 9 -backplane 7, 9 boot parameters 8, 33 BOOT_NO_AUTOBOOT 15 bootChange( ) 8, 12, 34 -Br 23 bspname.h 18 BSPs 7, 17 linux 7 Makefile 18 simpc 7 solaris 7 -Bt 23 building a VxWorks image 7, 43, 81 with vxprj 8 with Workbench 7 building applications 18
D
-d 9 debugging 20 DEFAULT_ACCESSMODE 60 DEFAULT_ERRORRATE 60 DEFAULT_EXTERNAL 60 DEFAULT_EXTPROMISC 60 DEFAULT_GARBAGE 60 DEFAULT_GID 60
125
DEFAULT_MACPREFIX 60 DEFAULT_TIMEOUT 61 DEFAULT_UID 60 development limitations 3, 45 -device 9 devs( ) 39 diab 18 DLL 117 dynamic-link library see DLL
host connection driver 63 32-bit Windows 64 64-bit Windows 65 Linux 66 Solaris 66 host system requirements 5 HOST_SIO_PORT_NUMBER -hostinet 9 -hostname 9, 37 hostSio 40
40
E
-e 9, 13 ELF object module format 20 emacs 57 -ethernet 9 examples vxsimnetd configuration file 80 exit hook facility 119 exiting the VxWorks Simulator 15 -exitOnError 9, 15
I
ifconfig( ) 69 INCLUDE_BOOT_LINE_INIT 7 INCLUDE_HOST_SIO 40 INCLUDE_IPCOM_SYSVAR_CMD 99 INCLUDE_IPD_CMD 99 INCLUDE_IPRADVD_CMD 99 INCLUDE_KERNEL 28 INCLUDE_MCB_SHOW 108, 111 INCLUDE_MIPC_DEMO 107, 108, 110, 111 INCLUDE_MIPC_SHOW 107, 110 INCLUDE_MIPC_SM 107, 108, 110, 111 INCLUDE_MND 107, 109, 110, 111 INCLUDE_MSD 107, 108, 110, 111 INCLUDE_NET_BOOT_CONFIG 69 INCLUDE_PASSFS 37 INCLUDE_PING 81, 90, 91, 109, 110, 111 INCLUDE_PING6 99 INCLUDE_ROUTECMD 81, 90, 91 INCLUDE_SM_COMMON 7, 41 INCLUDE_SM_NET 7, 41 INCLUDE_SM_OBJ 7, 41 INCLUDE_SYS_TIMESTAMP 40 INCLUDE_TIMESTAMP 40 INCLUDE_TIP 107, 109 INCLUDE_VIRTUAL_DISK 38 INCLUDE_WDB_PROXY_MIPC 107 INCLUDE_WDB_SYS 111 INCLUDE_WRLOAD 107, 108 INCLUDE_WRLOAD_IMAGE_BUILD 110, 111 -inet6 option 99 intConnect( ) 26, 27, 119, 120 intDisconnect( ) 119 interrupt assignments Windows simulator 27 interrupt simulation 25 host signals 25 on Linux and Solaris 25 on Windows 26 Windows messages 26
F
-f 9, 12, 56 -file 9, 56 file system support 3, 23 pass-through file system 23, 37 virtual disk 23, 38 -flags 9 floating-point routines 24 support 24 -force 56
G
-g 9 -gateway 9 gnu 18
H
-h 9 hardware breakpoint support 24 hardware simulation 37 -help 9 -hn 9, 37 host application interface 118
126
Index
IPv6 configuring into the VxWorks image 98 configuring support on the host 97 support 48 testing the connection 99 tutorial 97 ISR_STACK_SIZE 28
K
-k 9 -kill 9
L
-l 10 launching VxWorks simulator instances 83 -lc 10 linux 7 -list_dev 10 -list_dev all 10 -list_nat_redir 10, 73 -lnr 10 loading a VxWorks image 8 LOCAL_MEM_LOCAL_ADRS 34 LOCAL_MEM_SIZE 34 -logclean 10 -logfile 10
memory management unit 3, 21 limitations 22 MMU simulation 21 page size 22 translation Model 22 memory protection level 36 -memsize 11, 34 migrating applications 45 MIPC demo 114 tutorial 105 verifying connectivity 113 MIPC demo (component) 107, 110 MIPC Network Device (component) 107, 110, 111 MIPC Network Device (MND) 107, 109, 110, 111 configuring 114 MIPC over SM (component) 107, 108, 110, 111 MIPC Show routines (component) 107, 110 MIPC WDB Agent Proxy backend (component) 107 MIPC_SM_NODES 107, 108, 110, 111 MMU see memory management unit MMU simulation 21 MND configuring 114 MSD_NUM_DEVS 107 Multi-Os IPC serial device (component) 107, 110
N
-n- nvram 10 -netif 10 network daemon configuration file parameters 59 configuration files 59 setting up 76 starting on the host 77 network simulation 47 full network simulation 48 building 48 configuring a subnet 68 host connection driver 63 network daemon 50 network redirection 71 adding a redirection 72 default redirections 71 listing redirections 73 networking address space 28 -ni 10, 13, 68, 74 syntax on Linux and Solaris hosts 76 non-volatile RAM support 39 Number of MSD devices 107 NV_RAM_SIZE 39 -nvram 39
M
MACH_EXTRA 18 macros AUX_CLK_RATE_MAX 39 AUX_CLK_RATE_MIN 39 HOST_SIO_PORT_NUMBER 40 INCLUDE_SM_NET 7 LOCAL_MEM_LOCAL_ADRS 34 LOCAL_MEM_SIZE 34 MACH_EXTRA 18 NV_RAM_SIZE 39 SYS_CLK_RATE_MAX 39 SYS_CLK_RATE_MIN 39 Makefile 7, 18 Maximum nodes per bus 107, 108, 110 memory configuration 34 layout 28 memory management support running without MMU 22
127
O
-o 10 -other 10
S
-s 11, 56, 57 serial I/O driver 40 serial line support 40 setting up the network daemon 76 shared memory address space 28 END driver 7 pool size 7 size 7 shared memory network 40 -shell 56, 57 shell vxsimnetd 86 -shellport 56 -shellserver 56, 57 SIGALRM 25 SIGPOLL 25, 119 SIGUSR1 26 SIGUSR2 26 SIMLINUX 19 simnet 48 simnet_nat 71 SIMNT 19 simpc 7 SIMPENTIUM 20 SIMSPARCSOLARIS 20 simulated hardware support 3 simulating packet loss 58 SIO driver 39 -size 11, 34 SM_MEM_SIZE 7 SM_OBJ_MEM_SIZE 7 smEnd 7 SMP support 3 creating an image 43 system requirements 5 solaris 7 -sp 56 specifying the passFS device name 37 standard I/O 18, 39 starting a standalone VxWorks Simulator instance 12 a VxWorks simulator instance 77 simulator instances for use with network services 13 the network daemon on the host 77 the VxWorks Simulator from Workbench 14 -startup 11 subnet configuring 68 wrnetdlink 69 SUBNET_ACCESSMODE 61 SUBNET_ADDRESS 61 SUBNET_BROADCAST 62 SUBNET_ERRORRATE 62 SUBNET_EXTCONNNAME 63
P
-p 10, 13 packet loss 58 packet sniffers 48, 58, 63 passDev 9 passFS see pass-through file system pass-through file system 23, 37 -password 10 physical memory address space 34 Ping client (component) 110 -pl 11 -processor 10 -prot-level 11, 36 -pw 10
R
remote host 15 router configuration 13 routines bootChange( ) 34 bootChange( ) 8, 12 devs( ) 39 ifconfig( ) 69 intConnect( ) 119, 120 intDisconnect( ) 119 sysAuxClkRateSet( ) 39 sysBusToLocalAdrs( ) 18 sysClkRateSet( ) 39 sysMemTop( ) 28 sysNvRamGet( ) 39 sysNvRamSet( ) 39 virtualDiskClose( ) 39 virtualDiskCreate( ) 38 virtualDiskInit( ) 38 vxsimExitHookAdd( ) 119 vxsimFdIntDisable( ) 119 vxsimFdIntEnable( ) 119 vxsimHostDllLoad( ) 118 vxsimHostProcAddrGet( ) 118 vxsimIntAckRtnAdd( ) 120 vxsimIntRaise( ) 120 vxsimIntToMsg( ) 120 vxsimMsgToInt( ) 120 vxsimWindowsHandleGet( ) 120 RTP support 3, 23 running the MIPC demo 114
128
Index
SUBNET_EXTDEVNUM 62, 63 SUBNET_EXTERNAL 61 SUBNET_EXTPROMISC 62 SUBNET_GID 61 SUBNET_MACPREFIX 61 SUBNET_MASK 61 SUBNET_MAXBUFFERS 62 SUBNET_MAXNODES 62 SUBNET_MTU 63 SUBNET_MULTICAST 62 SUBNET_RECQLEN 62 SUBNET_SHMKEY 62 SUBNET_TIMEOUT 63 SUBNET_UID 61 supported VxWorks features 2, 6 -sv 56, 57 SYS_CLK_RATE_MAX 39 SYS_CLK_RATE_MIN 39 sysAuxClkRateSet( ) 39 sysBootLine 18 sysBusToLocalAdrs( ) 18 sysClkRateSet( ) 39 sysLib.c 18 sysMemTop( ) 28 sysNvRamGet( ) 39 sysNvRamSet( ) 39 system clock 39
U
-unit 11 UNIX disk driver library 38 unixDrv 38 unixSio.c 18, 39 -user 11 USER_INT_RANGE_BASE 120 USER_INT_RANGE_END 120 -username 11
V
-v 11 -vaddr 11, 35 -version 11 vi 57 virtual disk support 3, 23, 38 virtual memory address space 35 virtualDiskClose( ) 39 virtualDiskCreate( ) 38 virtualDiskInit( ) 38 VM_PAGE_SIZE 22 VM_STATE_CACHEABLE 22 VM_STATE_CACHEABLE_NOT 22 VM_STATE_VALID 22 VM_STATE_VALID_NOT 22 VM_STATE_WRITEABLE 22 VM_STATE_WRITEABLE_NOT 22 VMEbus 40 -vsize 11, 35 VxMP 7 vxprj 81, 90 VxSim accessing the console through a Telnet client 45 exceptions 123 vxsim 8, 12 configuration options 8 vxsimapi 117, 118 vxsimExitHookAdd( ) 119 vxsimFdIntDisable( ) 119 vxsimFdIntEnable( ) 119 vxsimHostArchLib 117 vxsimHostDllLoad( ) 118 vxsimHostProcAddrGet( ) 118 vxsimIntAckRtnAdd( ) 120 vxsimIntRaise( ) 120 vxsimIntToMsg( ) 120 vxsimMsgToInt( ) 120 vxsimnetd 50, 77 command-line options 55 configuration file example 80 debug shell 57 dynamic configuration 86 removing the Windows service 57 shell 86 shell commands 57
T
TAP driver 63 TAP-Win32 driver 65 WRTAP driver 64 TAP-Win32 driver 65 -targetname 11 testing an IPv6 connection 99 timers 39 timestamp driver 40 tip serial line connection utility 107 tip utility 107, 109, 114 -tmpdir 11 -tn 11 TOOL 18 ttySio 122 tun module 66 tutorial AMP with MIPC 105 IPv6 97 networking across multiple hosts with wrnetdlink 89 running the simulator on the local network 93 simple simulated network 76 simulated network with multiple simulators 79 tyLib.c 18
129
? 58 delete 58 errorrate 58 extpromisc 58 help 58 mode emacs 58 mode vi 58 node 57 packet 58 quit 58 source 58 subnet 57 timeout 58 starting as a root service 53 starting as a Windows service 53 static configuration 80 vxsimnetds_inst.exe 52 vxsimWindowsHandleGet( ) 120 vxWorks 7 VxWorks AMP tutorial 105 verifying connectivity 113 VxWorks bundles BUNDLE_AMP_PRI 107, 108, 111 BUNDLE_AMP_SEC 110 VxWorks components INCLUDE_BOOT_LINE_INIT 7 INCLUDE_HOST_SIO 40 INCLUDE_IPCOM_SYSVAR_CMD 99 INCLUDE_IPD_CMD 99 INCLUDE_IPRADVD_CMD 99 INCLUDE_MCB_SHOW 108, 111 INCLUDE_MIPC_DEMO 107, 108, 110, 111 INCLUDE_MIPC_SHOW 107, 110 INCLUDE_MIPC_SM 107, 108, 110, 111 INCLUDE_MND 107, 109, 110, 111 INCLUDE_MSD 107, 108, 110, 111 INCLUDE_NET_BOOT_CONFIG 69 INCLUDE_PASSFS 37 INCLUDE_PING 81, 90, 91, 107, 109, 110, 111 INCLUDE_PING6 99 INCLUDE_ROUTECMD 81, 90, 91 INCLUDE_SM_COMMON 7, 41 INCLUDE_SM_NET 41 INCLUDE_SM_OBJ 7, 41 INCLUDE_SYS_TIMESTAMP 40 INCLUDE_TIMESTAMP 40 INCLUDE_VIRTUAL_DISK 38 INCLUDE_WDB_PROXY_MIPC 107 INCLUDE_WDB_SYSVxWorks 111 INCLUDE_WRLOAD 107, 108 INCLUDE_WRLOAD_IMAGE_BUILD 110, 111 VxWorks image vxWorks 7 vxWorks.st 7 VxWorks image projects (VIPs) 7 VxWorks simulator network daemon see vxsimnetd vxWorks.st 7
W
watchdog timer facilities 25, 27 WDB back end 23 WDB_POOL_SIZE 28 Wind River System Viewer 40 winSio.c 18, 39 wrenv 78 WRLoad (build component) 107, 110 wrnetdlink 69 connecting simulated subnets 92 tutorial 89 WRTAP driver 63, 64
X
xterm 8
130

WR VX Simulator Users Guide 6.9

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

WR VX Simulator Users Guide 6.9

Diunggah oleh

Hak Cipta:

Format Tersedia

Wind River VxWorks Simulator User's Guide, 6.

Wind River VxWorks Simulator

Wind River VxWorks Simulator User's Guide 6.9

Getting Started ............................................................................................

Wind River VxWorks Simulator User's Guide, 6.9

Introduction to the VxWorks Simulator Environment .............................

Using the VxWorks Simulator ...................................................................

Networking with the VxWorks Simulator ..................................................

Wind River VxWorks Simulator User's Guide, 6.9

Configuring a Subnet Across Multiple Hosts Using wrnetdlink ...............

Networking Tutorials ..................................................................................

Tutorial: Simulating VxWorks AMP ........................................................... 105

Accessing Host Resources ....................................................................... 117

Wind River VxWorks Simulator User's Guide, 6.9

VxWorks Simulator Exceptions ................................................................. 123

Index ..................................................................................................................... 125

Wind River VxWorks Simulator User's Guide, 6.9

1.2 Supported Features and Compatibility

1.2.1 VxWorks Feature Support

1 Overview 1.3 Limitations

1.2.2 Simulated Hardware Support

Wind River VxWorks Simulator User's Guide, 6.9

2.2 System Requirements

Multiprocessor Simulation Requirements

Wind River VxWorks Simulator User's Guide, 6.9

2.3 Configuring and Building a VxWorks Image

2.3.1 Default Configuration Components

2 Getting Started 2.3 Configuring and Building a VxWorks Image

2.3.2 Configuring Optional Components

2.3.3 Building Your VxWorks Image

Wind River VxWorks Simulator User's Guide, 6.9

Windows Solaris Linux

simpc solaris linux

2.3.4 VxWorks Source Build (VSB) Projects

2.4 Launching the VxWorks Simulator

2.4.1 vxsim Configuration Options

2 Getting Started 2.4 Launching the VxWorks Simulator

Command-Line Options for the VxWorks Simulator

VxWorks Simulator Option

-add_dev serial0=telnet:[portNumber]: [nowait],[nokill]

Wind River VxWorks Simulator User's Guide, 6.9

Command-Line Options for the VxWorks Simulator (contd)

VxWorks Simulator Option

-list_dev serial0 -list_dev all

2 Getting Started 2.4 Launching the VxWorks Simulator

Command-Line Options for the VxWorks Simulator (contd)

VxWorks Simulator Option

Wind River VxWorks Simulator User's Guide, 6.9

2.4.2 Launching a VxWorks Simulator Instance from the Command Line

Modifying the Windows Simulator Console Appearance

2 Getting Started 2.4 Launching the VxWorks Simulator

Starting an Instance with Network Redirection (NAT)

Starting an Instance to Run on a Simulated Subnet

Assuming the following default subnet:

Wind River VxWorks Simulator User's Guide, 6.9

2.4.3 Launching the VxWorks Simulator from Workbench

2.4.4 Connecting to an Existing Simulator Instance from Workbench

2 Getting Started 2.4 Launching the VxWorks Simulator

2.4.5 Rebooting and Exiting the VxWorks Simulator

2.4.6 Accessing the VxWorks Simulator from a Remote Host

With Full Network Simulation (simnet)

On Linux hosts, run the following with root permissions:

or, edit /etc/sysconfig/network and add the following line: