Windmanage Cli Tutorial 4.3

4.
WIND MANAGE
COMMAND LINE INTERFACE
Tutorial
Copyright  2004 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, the Wind River logo, Tornado, and VxWorks are registered trademarks 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:
http://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 on your product media under the following directory:
installDir/docs/pdf/3rd_party_licensor_notice.
Corporate Headquarters
Wind River Systems, Inc.
500 Wind River Way
Alameda, CA 94501-1153
U.S.A.
toll free (U.S.): (800) 545-WIND

telephone: (510) 748-4100
facsimile: (510) 749-2010
For additional contact information, please visit the Wind River URL:
http://www.windriver.com
For information on how to contact Customer Support, please visit the following URL:
http://www.windriver.com/support
WIND MANAGE COMMAND LINE INTERFACE Tutorial, 4.3
8 Sep 04
Part #: DOC-15247-ZD-00
Contents
1 Getting Started ..................................................................................... 1
1.1 Introduction ............................................................................................................. 1
1.2 Tutorial Overview and Outline ........................................................................... 2
1.3 What You Need Before Starting ........................................................................... 3

1.3.1 The Tornado IDE ...................................................................................... 3
1.3.2 A Customized VxWorks Bootable Image ............................................. 3
1.3.3 WIND MANAGE CLI ............................................................................. 3
VxSim and BSP Issues ............................................................................. 3
Avoiding Telnet Conflicts ........................................................................ 4
1.4 Generated Code Overview ................................................................................... 4

CLI Engine Configuration and Command Files .................................. 5
Global Configuration File ....................................................................... 5
Backplane Configuration Files ............................................................... 5
Backplane Project Files ............................................................................ 6
2 Creating A Basic Command Line Interface ....................................... 7
2.1 Scalar GETs and SETs ............................................................................................ 7

2.1.1 Configure the WIND MANAGE CLI Project ....................................... 7
Create the Tutorial 01 WIND MANAGE Integration Tool project. ... 8
iii
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
Sample Device Data ................................................................................. 8

Set the WIND MANAGE Integration Tool Global Options ............... 8
Configuring the Backplane and the Component Interface ................ 9
2.1.2 Create the WindMarks ............................................................................. 11
2.1.3 Create the CLI Commands ...................................................................... 13
2.1.4 Generate the Files ..................................................................................... 16
2.1.5 Create the Tornado Project File .............................................................. 16
2.1.6 Build the WIND MANAGE CLI Application ...................................... 17
2.1.7 Run the WIND MANAGE CLI Application ......................................... 18
2.2 Access Control ......................................................................................................... 19

Types of Access Control .......................................................................... 20
2.2.1 Configure the WIND MANAGE CLI Project ....................................... 20
Assign Access Levels to Commands ..................................................... 21
2.2.2 Generate the Configuration and Command Files ............................... 22
2.2.3 Create the Tornado Project File .............................................................. 22
2.2.4 Build the WIND MANAGE CLI Application ...................................... 23
2.2.5 Run the WIND MANAGE CLI Application ......................................... 24
Access Control on a Command .............................................................. 24
Access control on Command Parameters ............................................. 25
Access control on WindMarks ................................................................ 26
A Setting up VxWorks, VxSim, and ULIP ............................................... 29
A.1 Creating a Custom Bootable VxWorks or VxSim Project ............................... 29

A.1.1 Create the Workspace and Custom Bootable Project .......................... 30
A.2 Customizing the VxWorks Image ....................................................................... 32

A.2.1 About the VxWorks Customizations ..................................................... 32
A.2.2 Customize VxWorks ................................................................................ 33
A.2.3 Build VxWorks .......................................................................................... 36
A.2.4 Boot the Customized VxWorks (VxSim) Image ................................... 36
iv
Contents
A.2.5 WDB Target Server Setup ........................................................................ 37

A.2.6 Launch a Shell and Verify the Connection ........................................... 39
Troubleshooting ........................................................................................ 39
A.3 Installing the ULIP Virtual Adapter ................................................................... 40

A.3.1 Installing ULIP on Windows XP ............................................................ 40
A.3.2 Installing ULIP on Windows 2000 ......................................................... 41
A.3.3 Installing ULIP on Windows NT 4.0 ..................................................... 43
Index .............................................................................................................. 45
v
Tutorial, 4.3
vi
1
Getting Started
1.1 Introduction 1
1.2 Tutorial Overview and Outline 2
1.3 What You Need Before Starting 3
1.4 Generated Code Overview 4
1.1 Introduction
This document is a companion to the WIND MANAGE CLI, WEB, MIBway
Programmer’s Guide. At a minimum, you should read the introductory and
overview chapters of that guide before beginning this tutorial so that you are
familiar with WIND MANAGE’s approach to device management, and command
line based device management in general.
The tutorial provides instructions to set up the included sample projects on a
Windows NT/2000/XP based full VxWorks simulator. These instructions should
be easy to adapt to an actual hardware target if the full simulator in not available
to you. The tutorial sample management projects are target platform independent,
so you should be able to build these projects for any supported BSP with minimal
modification.
1
Tutorial, 4.3
1.2 Tutorial Overview and Outline

This tutorial demonstrates the important features of WIND MANAGE CLI, and
shows you how to implement these features using the WIND MANAGE
Integration Tool (WMIT). During the tutorial, you will build several projects, each
of which highlights a set of related features. Each part of the tutorial is modular.
You can build only one part of the tutorial as desired, but the instruction is
progressive as later projects use the features and skills acquired earlier. The
modularity allows you to go back to a particular project as a refresher, or skip
ahead if you are already familiar with the concepts in a particular project. The end
result is that you will build a series of projects, several of which simulate actual
device management interfaces.
Each sequence of steps begins with a brief discussion of what you are about to do,
and finishes with a summary discussion that highlights the goals of that particular
sequence.
The initial project setup—which begins in 2.1.1 Configure the WIND MANAGE CLI
Project, p.7—is intended to familiarize you with the process of creating a WIND
MANAGE CLI project from scratch. In the interest of speeding things up and
reduce the redundancy within the main part of the tutorial., the second project file
is pre-configured and provided for you. The instructions in this tutorial use the
VxSim target simulator. If you use the simulator, it must be the full, network
enabled simulator. Some platforms do not support the simulator, and it may not be
available for use. In such cases, you should be able to use this tutorial and its
accompanying projects with a real target board as well. The differences between
the simulator and a real target are minimal, and are mostly limited to project setup
issues (BSPs and build specifications) and Tornado host tool configuration, such as
the WDB target server. This document does not discuss any target-specific issues
such as target bootstrap or hardware setup.
If possible, you should first run the tutorials on VxSim (for more information about
VxSim and product versions, see 1.3 What You Need Before Starting, p.3). After you
have successfully built the tutorial projects on the simulator, you can adapt these
instructions for use with a real target board.
After the initial setup is complete, the general outline for the tutorial is:
Project 01—Scalar GETs and SETs
Project 01 demonstrates WWIND MANAGE CLI project setup, build, and
scalar type GETs and SETs.
2
1 Getting Started
1.3 What You Need Before Starting
Project 02—Access Control 1

Project 02 extends the core of project 01 by adding basic access control on
commands and WindMarks, and explores the differences between the two.
1.3 What You Need Before Starting
1.3.1 The Tornado IDE
The projects and instructions in this tutorial are geared for the Tornado 2.2 IDE and
VxWorks 5.5 using a target board or the target simulator VxSim (simpc).
1.3.2 A Customized VxWorks Bootable Image
This tutorial requires a customized bootable VxWorks image for your target BSP.
For a description of the required customizations and instructions to create a
customized VxWorks image, see A. Setting up VxWorks, VxSim, and ULIP.
1.3.3 WIND MANAGE CLI
WIND MANAGE CLI, including the WIND MANAGE Integration Tool, must be
installed on your Windows host machine. These instructions assume that your
WIND MANAGE installation path is the same as your Tornado installation path
(identified by the environment variable %WIND_BASE% or $WIND_BASE ). If you
have installed WIND MANAGE in a different location, you must modify these
instructions and to reflect your actual WIND MANAGE installation location.
VxSim and BSP Issues
Every Tornado project file contains architecture/BSP specific information. Each

sample tutorial project file includes the necessary source and header files to build
a downloadable project based on the VxSim (simpc) build specification. If, after
running through these tutorials on VxSim, you want to port them to an actual
hardware target, all you need to do is add a build specification for your actual
3
Tutorial, 4.3
target BSP. Refer to the Tornado User’s Guide for information about adding a build
specification to a downloadable project.
NOTE: If you are unable to use the simulator, you must add the target specific build
spec before compiling the projects. These instructions indicate when you should
do this.
You cannot add a build specification for a different BSP to a bootable project, so your
custom configured VxWorks image based on VxSim cannot be reused for an actual
target. You will need to create a target-BSP specific VxWorks image. You can use
the instructions in A. Setting up VxWorks, VxSim, and ULIP, and substitute your
actual target BSP for VxSim.
Avoiding Telnet Conflicts
WIND MANAGE CLI implements a telnet daemon. VxWorks also implements a

telnet daemon, however the default VxSim configuration does not include the
telnet daemon. If you choose to implement the VxWorks telnet daemon in addition
to the WIND MANAGE CLI telnet daemon, you must modify the configuration of
one or the other in order to avoid both processes listening on port 23—the
well-known port for telnet connections. For information about configuring the
respective telnet daemons, see the WIND MANAGE Programmer’s Guide and the
VxWorks Programmer’s Guide.
1.4 Generated Code Overview

WIND MANAGE CLI provides a generalized body of target source code, and a
tool to generate the custom configuration files that port the generalized target code
to your target. You set the configuration options using the WIND MANAGE
Integration Tool, and the WIND MANAGE Integration Tool generates the target
code that contains and implements these customizations. On the host side, the
WIND MANAGE Integration Tool stores these configuration settings in the project
files projName.rcp and projName.ccp.
The following section describes how each of the WIND MANAGE Integration Tool
generated target files relates to a particular part of your project, and where it fits in
4
1 Getting Started
1.4 Generated Code Overview
the development process. Details, instructions, and information about the choices 1
available to you, begin in 2.1.1 Configure the WIND MANAGE CLI Project, p.7.
CLI Engine Configuration and Command Files
The embedded CLI engine configuration files, wmc_projName.c/h and

wmw_httpconf.c, contain various compiler directives, and constant declarations
that define server specifications, configuration, protocol features. These files—as
with all WIND MANAGE source files containing an underscore [_] character—are
generated by the WIND MANAGE Integration Tool. Do not manually edit these
files because your edits will be overwritten on subsequent re-generation. The only
exceptions are the files wmb_projName.c/h, which you can edit in special use code
blocks.
In those cases where you want or need to put your own code in these generated
files, the WMIT provides the extensions facility. For information about using
extensions, see the WIND MANAGE Programmer’s Guide, or the WIND MANAGE
Integration Tool online help.
Global Configuration File
The global configuration file, wm_options.h, contains settings that apply to all
projects within the device, for example, the byte-ordering (endian-ness) of the
target CPU. In practice, you may use one wm_options.h file for a project and
several sub projects. In this tutorial, each project is a stand-alone application and
has its own wm_options.h file.
Backplane Configuration Files
The backplane configuration file, wmb_options.h, contains configuration settings

for the backplane implemented in the current project. If a project attaches to an
external backplane, it will not use this file. In this tutorial, each project that
instantiates a backplane is a stand alone application and has it’s own
wmb_options.h file.
5
Tutorial, 4.3
Backplane Project Files
The WindMarks you create and define represent the manageable elements of the
device. Using the WIND MANAGE Integration Tool, you will create WindMarks
that represent these manageable elements, and associate handler code with each of
them.
Handler code (sometimes called glue code) may be created before or after
generating the project files. If you create WindMarks without handler code, the
WIND MANAGE Integration Tool generates stubs (the function name and
parameters where you enter your handler code), or you can create the glue code
functions first, then use their names when you enter the information in the
WIND MANAGE Integration Tool.
wmb_projectName.c/h
These files contain the WindMark registration routines, the embedded CLI
engine startup and registration routines, and the WindMark handler code.
6
2
Creating A Basic Command
Line Interface
2.1 Scalar GETs and SETs 7

2.2 Access Control 19
2.1 Scalar GETs and SETs

For the first WIND MANAGE CLI project, you will create a basic command tree
that implements five commands. Three of these commands display the stored
value of some device resident variables, and the other two allow you to set new
values for two of those same variables.
2.1.1 Configure the WIND MANAGE CLI Project
You need to create a WIND MANAGE project file. This project file retains all of the
project specific configuration settings you make. The project itself is not actually
compiled into the Tornado project, but the configuration files the
WIND MANAGE Integration Tool generates for your project are. In this sequence,
you will set the CLI engine configuration options and generate the configuration
and command files.
7
Tutorial, 4.3
Create the Tutorial 01 WIND MANAGE Integration Tool project.
Launch the WIND MANAGE Integration Tool . The first time the
WIND MANAGE Integration Tool starts up, it opens with the project named
default.rcp. You will need to Save As another project name. As you did with the
Tornado project, you should name this file tutorial01.rcp to be consistent with the
pre-configured projects and put it in the same directory tree as the other projects.
1. From the Tools menu, select Preferences.
2. In the General tabbed page, select WindManage CLI, and uncheck the other
boxes. The remaining tabbed pages relate to features or products you are not
using for this tutorial. You can ignore them for now
3. From the File menu, select Save As. Save this project as
installDir/tutorials/windmanage/cli/tutorial01/tutorial01.rcp. Be sure to
substitute your actual WIND MANAGE install path.
4. Click OK.
Sample Device Data
Another file included for compilation in the Tornado project is the sample client
programmer implemented file,
installDir/tutorials/windmanage/cli/sampleDevice.c and its corresponding
header file installDir/tutorials/windmanage/cli/sampleDevice.h. These files
define and initialize a set of sample device resident variables that WIND
MANAGE CLI accesses using WindMark and SET operations. In a production
device, the variables you GET and SET may be implemented in a variety of places,
such as SNMP Management Information Base files (MIBs), custom device code,
and so forth. This sampleDevice.c file is intended to be a simple example of device
resident management variables, not something you would recreate for a project.
Set the WIND MANAGE Integration Tool Global Options
These options apply to all of the components in a WIND MANAGE project. In

practice, the scope of these settings is global within the embedded OS or memory
space.
1. Set the generated file output locations.
a. In the WIND MANAGE Integration Tool , select Project > Settings.
8
2 Creating A Basic Command Line Interface
b. In the left pane of this window, select Directories. 2

c. The locations for the generated files are specified here by file type. use the
default values—which are the same location as the project file—for this
tutorial. This will ensure that the generated files are properly referenced in
the Tornado project file.
NOTE: Portfolios are not yet supported for CLI, but you still must provide a
location for the generated portfolio file.
2. Set the System Specifications. These are settings that apply to the project as a
whole, such as compiler typedefs, and target CPU endian-ness.
a. In the left pane of this window, select System Specifications.
b. Verify that these values match your target hardware and toolchain, and if
they don’t, change them accordingly.
3. Configure local ANSI libraries.
a. In the left pane of this window, click WindManage Backplane.
b. Click the General Configuration tab.
c. In the Image Size group, check Use Local ANSI Libraries.
This setting specifies that WIND MANAGE CLI will use the ANSI
standard libraries provided by target OS. In cases where the target OS does
not have ANSI standard libraries, you can use the WIND MANAGE ANSI
standard libraries by clearing this box.
4. Do not click OK yet! There are more configuration options to set.
Configuring the Backplane and the Component Interface
These settings indicate how the component (the CLI engine in this case) will
interface and register with the backplane.
1. Configure/verify the Component Interface.
a. From the Project menu, select Settings.
b. In the left pane, select Component Interface, then click the Component
tab.
c. In the Resource Registration group, Static Registration for CLI should be
checked.
9
Tutorial, 4.3
d. Click the Backplane tab, and make sure Instantiate a WMB is selected.
e. Leave the default values for max resources, max components and
registration timeout.
f. Verify that parent WMB is unchecked.
The parent WMB setting indicates that the WMB being instantiated in this
project will connect to a named parent WMB elsewhere in the embedded
system. This is a special use case, and not typical in a single memory space
system. Similarly, Port and Named pipe listener apply to communication
between backplanes in a multiple backplane system.
g. Click the WM consumers tab. Instantiate the CLI Server should be
checked, and the other selections should be grayed out.
h. Click the Events tab, and verify that No Event Manager is selected.
WIND MANAGE events are used for runtime HTTP server configuration,
and not needed for WIND MANAGE CLI.
i. Click the NVM tab, and verify that No None is selected. NVM+ support
is not used in these tutorial projects.
2. Configure the backplane.
a. Click the Input tab. The file sampleDevice.h should be listed in the header
files section. If it is not, click the browse button, and navigate to
installDir//tutorials/windmanage/cli, select sampleDevice.h, click Open,
then click Add. This is the only header you need to add for this project.
When you have multiple header files, you can use this window to order
them.
b. Default values for the remaining backplane configuration and security
settings will work fine.
3. For this project, the default WIND MANAGE CLI engine configuration
settings are acceptable, however you do need to add one statement.
a. In the left pane, select WindManageCLI, then click the Extensions tab.
b. Enter the following line in the Extensions field:
#define RCC_AUTH_CALLBACK_FN RCC_TASK_ValidateLogin
This defines the RCC_TASK_ValidateLogin( )—the sample

authentication callback function—as the authentication callback function
to use.
c. Click OK.
10
2.1.2 Create the WindMarks 2
This tutorial uses some sample WindMarks whose values the embedded CLI
engine displays and allows you to update. The variables (and the device data they
contain) are provided for you in the file
installDir//tutorials/windmanage/cli/sampleDevice.c You need to create the
WindMarks that represent these device resident variables. In the following steps,
you should use the WindMark names specified to be consistent with these
instructions, but it is not explicitly necessary. These WindMark names are arbitrary,
and you can easily change them if you wish.
1. Create the first WindMark.
a. In the WMIT project window, click the WindMark tab.
b. Right click in the project space and select Add WindMark.
c. In the WindMark editor that appears, give the new WindMark a name. Use
the name sysDescr.
d. In the type selector, choose string.
e. Leave permissions at zero (0). Any other values will cause problems at this
point.
f. You can enter developer notes in the Notes section. Notes are stored in the
project file, not in the generated embedded code.
g. In the Cookie Type selector, choose Absolute Address, and for the cookie
value, enter x_sysDesrc.
In the sample device implementation file the variable x_sysDescr is
declared as a ubyte[32]. So your settings here indicate that the data this
WindMark (sysDescr) represents is stored in the array x_sysDescr[32],
whose address is x_sysDescr.
In the Handler section, make sure the Lock Type is User. If it is
not, click (re)configure handler button, and change the Locking
type to By User (or none).
h. Click Apply.
At this point, the variable x_sysDescr has been defined and initialized (in
sampleDevice.c) and declared (in sampleDevice.h), and you have created a new
a new WindMark named sysDescr whose handler will GET or SET a string value
to the address x_sysDescr. This is all that needs to be done for basic string data (or
scalar) substitution.
11
Tutorial, 4.3
2. Create the sysName WindMark.

Since this WindMark will also represent a string, and the other settings are the
same, all you need to change is the WindMark name and the data cookie
address.
a. In the WindMark editor that is still open, enter sysName in the Name
field .
b. In the Cookie Type selector, leave Absolute Address, and for the cookie
value, enter x_sysName.
In the sample device implementation file the variable x_sysName is
WindMark (sysName) represents is stored in the array x_sysName[32],
whose address is x_sysName.
c. In the Handler section, make sure the Lock Type is WindMark (not
WindMark Group). If it is not, click (re)configure handler button, and
change the Locking type to By WindMark.
d. Click Apply.
3. Create the sysContact WindMark.
Since this WindMark will also represent a string, and the other settings are the
same, all you need to change is the WindMark name and the data cookie
address.
a. In the WindMark editor that is still open, enter sysContact in the Name
field.
b. In the Cookie Type selector, leave Absolute Address, and for the cookie
value, enter x_sysContact.
In the sample device implementation file the variable x_sysContact is
WindMark (sysContact) represents is stored in the array
x_sysContact[32], whose address is x_sysContact.
c. In the Handler section, make sure the Lock Type is WindMark (not
WindMark Group). If it is not, click (re)configure handler button, and
change the Locking type to By WindMark.
d. Click Apply, then close this window.
12
2.1.3 Create the CLI Commands 2
1. Create the Show node.

a. In the WMIT project window, click the Command tab.
b. Right-click the root node, and select Add Node.
c. In the Command Node Editor that appears, enter show in the Node Name
field.
d. Make sure Help String is selected, but there is o need to enter a value at
this point.
Though it is not apparent yet, show will be an intermediate node. An
intermediate node is a node that has no functionality when entered by
itself. An intermediate node must precede another node, such as
show sysName. Since show by itself really does not do anything, a help
string would not provide much meaning (at least in this case).
e. Do not check Enable Intermediate Mode for this node.
You will do this for the set node. Then you can observe the different
behavior when you run the application.
f. Click Apply.
2. Create the Set Node.
g. Right-click the root node, and select Add Node.
h. Enter set in the Node Name field.
i. Again, make sure Help String is selected, but you can leave the value
blank.
j. Check Enable Intermediate Mode for this node.
k. Enter Type ? for a list of options. in the prompt string field.
l. Click Apply.
3. Create the show sysName node.
a. Right-click the show node, and select Add Node.
b. Enter sysName in the Node Name field.
c. Select Help String and enter a useful description of what the command
does. Something like Displays the NIS name of this device. is suitable
for this tutorial.
13
Tutorial, 4.3
d. Uncheck Enable Intermediate Mode for this node.

e. Click Apply.
4. Add a handler for show sysName.
At this point, you have created the command nodes for set sysName.
However the node sysName is not functionally any different from show at this
point. You must now add a command handler to this node. By adding a
handler, you indicate that the CLI engine must execute some functionality
when a user enters show sysName.
a. In the Handler Functions section of the Command Node Editor, click
Add.
b. In the Handler Function Editor that appears, enter myShowSysName in
the Handler Name field.
c. Click OK to save the handler function and dismiss this window.
d. In the WindMark section of the Command Node Editor, click GET.
e. Select sysName from the list, and click OK.
f. Click Apply.
At this point, you have created the node and handler that reads and
displays the value of a scalar variable. However, you have to generate files
before you can actually see this handler code.
5. Add handler for show sysDescr and show sysContact.
a. Repeat step 4 above substituting sysDescr for the node name, and
myShowSysDescr for the handler name.
b. Repeat step 4 above substituting sysContact for the node name, and
myShowSysContact for the handler name.
6. Create the set sysName node.
The process for creating a node with a SET handler is very similar. All you
need to do differently is enable custom handler code and create a command
parameter to store the new value you wish to set.
a. Right-click the set node, and select Add Node.
b. Enter sysName in the Node Name field.
c. Select Help String and enter a useful description of what the command
does. Something like Enter a new value for the NIS name of this device.
is suitable for this tutorial.
14
d. Uncheck Enable Intermediate Mode for this node. 2

e. Click Apply.
7. Add a parameter for set sysName.
This parameter will hold the value for sysName. Since the intent of this
command is to set a new value for sysName, this is a required parameter.
a. In the Parameters section of the Command Node Editor, click Add.
b. Enter val_sysName (or another suitable name) in the Parameter Name
field.
c. Ensure that the data type is set to string, since the WindMark you will set
this value to is also a string data type.
d. Check Set WindMark, and select sysName.
e. Select Help String and enter a suitable description of this parameter.
Something like Enter a new device NIS name 0 to 31 characters long.
will work for this exercise.
f. Click OK.
8. Add a command handler for set sysName.
a. In the Handler Functions section of the Command Node Editor, click
Add.
b. In the Handler Function Editor that appears, enter mySetSysName (note
that is not myShowSysName) in the Handler Name field.
c. In the Available Parameters list, select val_sysName, then click Required.
d. In the Legacy Custom Handler Code section, Check
Enable Custom Handler Code.
e. Click OK to save the handler function and dismiss this window.
f. Click Apply.
At this point, you have created the node and handler that reads a
parameter from the command line, stores that value in val_sysName, then
passes val_sysName to the sysName WindMark handler to update the
value of that variable. Again, you must generate files before you can
actually see this handler code however.
9. Add parameters for set sysDescr, and set sysContact.
15
Tutorial, 4.3
a. Repeat step 7 above for set sysDescr using val_sysDescr as the

Parameter Name, and sysDescr as the Set WindMark name.
b. Repeat step 7 above for set sysContact using val_sysContact as the
Parameter Name, and sysContact as the Set WindMark name.
10. Add command handlers for set sysDescr, and set sysContact.
a. Repeat step 8 above for set sysDescr using mySetSysDescr as the
Handler Name, and val_sysDescr as the required parameter.
b. Repeat step 8 above for set sysContact using mySetSysContact as the
Handler Name, and val_sysContact as the required parameter.
Now you have created a command tree with two intermediate nodes, set and
show; each of which has three leaf nodes, sysDescr, sysName, and sysContact.
The set intermediate node has intermediate mode enabled, and the show node
does not.
2.1.4 Generate the Files
Now that you have set the configuration options, created the WindMarks, and
created the command tree, you need to generate the target files.
1. Generate the Files.
a. From the Build menu, select Generate All.
b. Click OK to dismiss each success message.
c. Save your WMIT project file, and minimize the WMIT.
2.1.5 Create the Tornado Project File
You will use the project creation script prjCreate.tcl to create a Tornado project file
(.wpj) and a Makefile based on the WMIT project you have just created. Before you
run the script, make sure you have generated files (see 2.1.4 Generate the Files, p.16).
1. Set the Tornado environment variables.
a. Open a command prompt (a DOS shell).
b. Enter installDir/host/x86-win32/bin/torVars.bat
c. Press ENTER.
16
NOTE: It is possible to install WIND MANAGE outside the Tornado tree. If 2

WIND MANAGE is installed outside the Tornado tree, you must set the
WM_BASE environment variable. If WIND MANAGE is installed in the same
tree as Tornado, you do not need to set this variable.
2. If WIND MANAGE is not installed in the same installation location as

Tornado, set the WM_BASE environment variable.
a. Refer to the documentation for your host operating system for instructions
to set an environment variable.
b. Set the variable name WM_BASE, and the value should be your full WIND
MANAGE installation path.
3. Run the script.
a. At the command prompt, change directories [cd] to
installDir//tutorials/windmanage/cli/tutorial01.
b. Enter the following command:
wtxtcl installDir/host/src/wrn/wm/makescripts prjCreate.tcl SIMNT gnu
c. Press ENTER.
NOTE: If you are using this tutorial on a real target, substitute SIMNT and gnu with
the actual CPU and toolchain values you are using. Do not precede these values
with parameter names such as CPU= or TOOL= . Just use the values, as in SIMNT
and gnu, or PPC860 and diab.
2.1.6 Build the WIND MANAGE CLI Application
Now it is time to build and run WIND MANAGE CLI on your custom configured
VxWorks image. If you do not already have a Tornado workspace created, you
should create one now using the instructions in A. Setting up VxWorks, VxSim, and
ULIP, otherwise, open the TORNADO workspace that contains your customized
VxWorks bootable image now.
1. Add tutorial01.wpj to your Tornado workspace, an build it.
a. In the Tornado project facility window, right-click the workspace, and
select Add Project. Navigate to
installDir/tutorials/windmanage/cli/tutorial01, and select tutorial01.wpj.
b. Click Add.
17
Tutorial, 4.3
c. Right-click tutorial01 and select Build tutorial01.out.

d. When the build finishes, close the build output window.
e. Select the custom target server you created (see A.2.5 WDB Target Server
Setup, p.37) from the list of available target servers in the Tornado toolbar.
f. Right-click tutorial01 and select Download tutorial01.out.
2. Launch WIND MANAGE CLI.
a. From the Tools menu, select Shell.
b. In the shell, enter WMB_COMPONENT_Start.
c. Press ENTER.
The shell command should return a value of zero (0x0).
2.1.7 Run the WIND MANAGE CLI Application
1. Connect to the embedded telnet server.

a. If the command prompt you used to create the project is still open, use it
to telnet to your VxWorks simulator. If not, open another one and enter
telnet 90.0.0.1.
b. Press ENTER.
c. At the login: prompt, type admin.
d. At the password prompt, type admin.
After logging in, you should see CLI#.
2. Display some of the variables with the show command.
a. At the CLI# prompt, enter show sysDescr, then press ENTER. This
command should display the value of x_sysDescr as it is initialized in the
file sampleDevice.c.
b. Do the same for the other leaf nodes under show, and verify that they work
as expected.
3. Experiment with the shell behavior: command completion.
a. At the CLI# prompt, enter show?. This command lists the available
subnodes for show.
b. At the CLI# prompt, enter show sys, then press TAB. Since this command
is ambiguous, the CLI engine lists possible matches.
18
2.2 Access Control
c. Clear the previous entry, the enter show sysD, then press TAB. Since this 2
command is no longer ambiguous, the CLI engine completes the text, and
displays show sysDescr on the command line. Press ENTER to execute
show sysDescr.
4. Experiment with the shell behavior: intermediate mode.
a. At the CLI# prompt, enter set, then press ENTER. Since you enabled
intermediate mode for set, the prompt changes to set-> (which is the
prompt string value you entered when you enabled intermediate mode for
this node) and all commands you enter here are relative to the
intermediate node set.
b. At the set-> prompt, enter sysDescr MyCLI. Note that in intermediate
mode, you only need to type the name of the leaf node and if required any
parameters.
c. To exit intermediate mode, at the set-> prompt, press CTRL + z. This
returns the prompt string to its default value CLI#.
d. At the CLI# prompt, enter set sysName CLI_simulator, then press ENTER.
This sets the value of the WindMark sysName to CLI_simulator. Now that
you are not in intermediate mode, you must type the entire command:
intermediate node leaf node requiredParameter ENTER.
2.2 Access Control

For the second tutorial project, you will add access control to a project similar to the
one you created in tutorial 01. Access control is the process of allowing or denying
a user permission to access a command or WindMark by comparing the users
permission level to the level required to access the command or WindMark. This is
different from authentication, which is the process of verifying the authenticity of
a user at login. This tutorial project does not discuss authentication.
This project is preconfigured for you so that you can leave the first tutorial project
and return to it for reference as you need to.
19
Tutorial, 4.3
Types of Access Control
There are three types of access control in WIND MANAGE CLI.

Command level access control
Using command level access control, you can restrict access to individual
commands. An example would be a command to show all users currently
logged onto the device. This might be a useful command for a system
administrator, but probably not desirable for all users.
Parameter level access control
Using parameter level access control, you can create commands that have
different options for different users. If a user does not have the appropriate
access level to access a particular parameter, that parameter will not be
available to that user.
WindMark level access control
Using WindMark level access control, you can restrict get or set access to
WindMark objects or groups. You might want to allow certain users
read/write privileges while only allowing other users read-only privileges.
2.2.1 Configure the WIND MANAGE CLI Project
This project is pre-configured for you, and is very similar to the first tutorial
project. This section describes how to implement the access control scheme used in
this project, but the actual work is already done for you.
The global settings, the component-backplane interface settings, and the CLI
engine options are all the same as in the project tutorial01.rcp that you created
earlier. The main differences are that one of the WindMarks and one of the
commands now have access levels set. In addition to this, this project uses a
modified version of the default authentication callback function. The default
sample has been modified to add another user. This modified sample validation
function is provided in a separate file in
installDir//tutorials/windmanage/cli/tutorial02. This file is automatically included
for compilation in the Tornado project you will create with prjCreate.tcl. For more
information about the prjCreate.tcl utility, see the WIND MANAGE CLI, WEB,
MIBway Programmer’s Guide, 4.1.
20
2.2 Access Control
NOTE: To speed things up a bit, you can skip ahead to 2.2.2 Generate the 2
Configuration and Command Files, p.22, then while the build is proceeding, come
back here to review the steps used to configure the access control implemented in
this project.
The following section covers the steps necessary to implement the access control
scheme used in this project.
Assign Access Levels to Commands
In this project, the command set sysName (specifically the subnode sysName) has
restricted access. The intent is to allow the user admin access to this command, and
deny access to user2.
1. Open tutorial02.rcp if it is not already open.
a. In the WIND MANAGE Integration Tool, select File > Open.
b. Navigate to installDir//tutorials/windmanage/cli/tutorial02, and select
tutorial02.rcp, then click Open.
c. If you have unsaved changes in an open WMIT project, you will be
prompted to save those changes prior to opening a new file. Save the
changes now.
2. Add an access level to the subnode sysName.
a. In the WIND MANAGE Integration Tool workspace, click the Command
tab.
b. Click the + next to set to expand the set intermediate node.
c. Double-click the command node sysName to open sysName in the
Command Node Editor.
d. Enter 7 in the Access field of the Properties box.
e. Click Apply, then click Close.
3. Add an access level to the WindMark sysContact.
a. In the WIND MANAGE Integration Tool workspace, click the WindMark
tab.
b. Double-click the WindMark sysContact to open it in the WindMark Editor.
c. Enter 7 in Write Access field of the Permissions box.
21
Tutorial, 4.3
This setting allows all users read access to the sysContact WindMark, but
only users with an access level greater than 7 can write information to the
sysContact WindMark.
d. Click Apply, then click Close.
This is all you need to do to implement access control on commands or
WindMarks. Though this tutorial does not demonstrate parameter-level access
control, you can also add access control to command parameters. The process is
similar to adding access control to command nodes, except that you specify access
levels in the Parameter Editor rather than the Command Node Editor.
2.2.2 Generate the Configuration and Command Files
1. Generate the files.

a. In the WIND MANAGE Integration Tool, select File > Open.
b. Navigate to installDir//tutorials/windmanage/cli/tutorial02, and select
tutorial02.rcp, then click Open.
c. If you have unsaved changes in an open WIND MANAGE Integration
Tool project, you will be prompted to save those changes prior to opening
a new file. Save the changes now.
d. From the Build menu, select Rebuild All, then dismiss each of the success
messages.
2.2.3 Create the Tornado Project File
You will use the project creation script prjCreate.tcl to create a Tornado project file
(.wpj) and a Makefile based on this WIND MANAGE Integration Tool project.
Before you run the script, make sure you have generated files (see 2.2.1 Configure the
WIND MANAGE CLI Project, p.20).
1. If the command prompt you used in the first project is still open, use it.
Otherwise open a new command prompt and set the Tornado environment
variables.
a. Open a command prompt (a DOS shell).
b. Enter TornadoInstallDir/host/x86-win32/bin/torVars.bat
c. Press ENTER.
22
2.2 Access Control
NOTE: It is possible to install WIND MANAGE outside the Tornado tree. If 2

WIND MANAGE is installed outside the Tornado tree, you must set the
WM_BASE environment variable. If WIND MANAGE is installed in the same
tree as Tornado, you do not need to set this variable.
2. If WIND MANAGE is not installed in the same installation location as

Tornado, set the WM_BASE environment variable.
a. Refer to the documentation for your host operating system for instructions
to set an environment variable.
b. Set the variable name WM_BASE, and the value should be your full WIND
MANAGE installation path.
3. Run the script.
a. At the command prompt, change directories [cd] to
installDir//tutorials/windmanage/cli/tutorial02.
b. Enter the following command:
wtxtcl installDir/host/src/wrn/wm/makescripts prjCreate.tcl SIMNT gnu
c. Press ENTER.
NOTE: If you are using this tutorial on a real target, substitute SIMNT and gnu with
the actual CPU and toolchain values you are using. Do not precede these values
with parameter names such as CPU= or TOOL= . Just use the values, as in SIMNT
and gnu, or PPC860 and diab.
2.2.4 Build the WIND MANAGE CLI Application
If the Tornado workspace you created earlier is not open, open it now.
1. Add tutorial02.wpj to the Tornado workspace, an build it.
a. In the Tornado project facility window, right-click the workspace, and
select Add Project. Navigate to
installDir/tutorials/windmanage/cli/tutorial02, and select tutorial02.wpj.
b. Click Add.
c. Right-click tutorial02 and select Build tutorial02.out.
d. When the build finishes, close the build output window.
23
Tutorial, 4.3
e. Select the custom target server you created (see A.2.5 WDB Target Server
Setup, p.37) from the list of available target servers in the Tornado toolbar.
f. Right-click tutorial01 and select Download tutorial01.out.
2. Launch WIND MANAGE CLI.
a. From the Tools menu, select shell.
b. In the shell, enter WMB_COMPONENT_Start.
c. Press ENTER.
The shell command should return a value of zero (0x0).
2.2.5 Run the WIND MANAGE CLI Application
1. Connect to the embedded telnet server as user admin.

a. If the command prompt you used to create the project is still open, use it
to telnet to your VxWorks simulator. If not, open another one and enter
telnet 90.0.0.1.
b. Press ENTER.
c. At the login: prompt, type admin.
d. At the password prompt, type admin.
2. Connect to the embedded telnet server as user user2.
a. Open a new command prompt and enter telnet 90.0.0.1.
b. Press ENTER.
c. At the login: prompt, type user2.
d. At the password prompt, type user2.
Access Control on a Command
At this point, you have two different telnet sessions connected to the CLI engine,
each of which have different access levels: user admin is defined as access level 10,
an d user user2 is defined as access level 5. In this situation, user2 can access
resources defined with an access level of 5 or lower. The user admin can access
24
2.2 Access Control
resources specified with an access level of 10 or lower. Since the command 2

set sysName in this project has an access level of 10, only the user admin can access
this command. It is important to note that this access restriction only applies to the
command, not necessarily the WindMark that this command’s handler accesses.
The effect of this is that admin can execute the command, but set sysName is not
available to user2. In fact, user2 does not even know that set sysName exists. If
user2 enters set?, only the commands available to user2 will display in the help
menu. In this example, the command set sysContact is accessible, but set sysName
is not, so user2 will only see (or have access to) set sysContact. The following
demonstrates access control on a command.
1. Enter the set intermediate mode as admin.
a. In the telnet session where you are logged on as admin, enter set, then
press ENTER. The prompt will change to set->.
b. At the set-> intermediate mode prompt, press ?.
The built in ? command displays a list of the available subnodes to the
current node. In this situation, you will see sysContact, and sysName,
along with their associated help strings.
2. Enter the set intermediate mode as user2.
a. In the telnet session where you are logged on as user2, enter set, then press
ENTER. The prompt will change to set->.
b. At the set-> intermediate mode prompt, press ?. In this situation, you will
only see sysContact.
The subnode sysName is not visible since user2 does not have an
appropriate access level to access this resource.
Access control on Command Parameters
In situations where you want two different users with different access levels to have
access to the same command, but with different functionality, you can assign access
levels to parameters. Just as in command access levels, users will only see
command parameters for which they have access.
The following example is not implemented in this project. It is intended to
summarize parameter access control. Suppose you have implemented the
following command:
show system status
25
Tutorial, 4.3
You might want to display some basic information, such as uptime, or error
conditions to general users. For administrators, you might want to display a list of
all users currently logged into the device. You could create an optional parameter
(for example -users) with an access level higher than that of general users, and
lower or equal to administrators. In this case, only administrators would see ( or
have use of) the optional parameter -users. General users would not even know it
existed, and if they tried to use it, the CLI engine would return an invalid
parameter message.
Access control on WindMarks
You can also restrict access to WindMark resources. WindMark-level access control
can be used with or without command or parameter level access control. The user
interface behavior is a bit different though. If you implement a command without
access control, and it sets or gets a WindMark with access control. The user must
have an access level greater or equal to that of the WindMark for the operation to
succeed. If the user does not have a sufficient access level, the command will return
the message Error: Access Denied. In this project, the two commands that set
WindMarks (set sysContact, and set sysName) each employ a different approach
to access control. The command set sysName has access control placed on the
command and not the WindMark. The command set sysContact, has access control
on the underlying WindMark sysContact, but not on the command. In the
following steps, you will interact with each approach.
1. Enter the command set sysName as admin.
a. Go to the telnet session where you are logged on as admin, you should
already be in the set-> intermediate mode.
b. Press ? to display a list of the available subnodes. This list should include
sysContact, sysName, and their associated help strings.
c. Enter sysName “Second Sim” then press ENTER. This command should
set and echo successfully.
2. Show the available command subnodes as user2.
a. Go to the telnet session where you are logged on as user2, you should
b. Press ?.
This list should only include sysContact and its associated help string,
since user2 does not have permission to access the subnode sysName.
26
2.2 Access Control
3. Enter the command set sysContact as admin. 2

a. Go to the telnet session where you are logged on as admin, you should
b. Enter sysContact “simulated person” then press ENTER.
This command should set and echo successfully.
4. Attempt to set sysContact as user2.
a. In the telnet session where you are logged on as user2, you should already
be in the set-> intermediate mode.
b. Enter sysContact “simulated person” then press ENTER.
This command should return an Error: Access Denied message.
This command returns an error, because user2 has an appropriate access
level to access the command, but does not have an appropriate write
access level for the WindMark resource the command modifies.
27
Tutorial, 4.3
28
A
Setting up VxWorks, VxSim,
and ULIP
A.1 Creating a Custom Bootable VxWorks or VxSim Project 29

A.2 Customizing the VxWorks Image 32
A.3 Installing the ULIP Virtual Adapter 40
A.1 Creating a Custom Bootable VxWorks or VxSim Project

If the full (networking enabled) VxWorks target simulator, VxSim is available and
supported for use with your platform product, you can use this tutorial project
with the simulator.
Use the following instructions to create a customized VxWorks simulator that
includes all of the features required to use this tutorial.
You can also use these instructions as a guide for creating a new bootable VxWorks
project and customized VxWorks image for a real target. The steps for creating a
bootable simulator project versus a bootable real target project are minimal. The
main difference is that you choose the BSP for your target device rather than the
VxSim BSP.
If you plan to use VxSim on Windows (the SimNT BSP), you must also install and
configure the User-Level Internet Protocol Virtual Adapter (ULIP). For instructions to
install and configure ULIP, see A.3 Installing the ULIP Virtual Adapter, p.40.
29
Tutorial, 4.3
A.1.1 Create the Workspace and Custom Bootable Project
Step 1: Confirm that the full VxSim product is installed

1. Open TORNADO.
2. From the Help menu, select About Tornado.
3. In the About Tornado dialog, select Details.
4. In the Installed Products window, scroll down to find
Tornado Full Simulator: x86-win32 (see Figure A-1).
NOTE: If the full simulator is not installed, you must either obtain a license for and
install the full simulator, or configure a supported VxWorks target and modify
these instructions for use with that target.
5. Click OK.
Figure A-1 The Tornado 2.2 Installed Products window
Step 1: Create a new workspace.

1. Launch TORNADO.
2. The Open Workspace dialog should appear. If not, click
File > Open Workspace.
3. Click the New tab.
30
A Setting up VxWorks, VxSim, and ULIP
A.1 Creating a Custom Bootable VxWorks or VxSim Project
4. Select Create a Bootable VxWorks Image (custom configured), then click

OK.
5. In the wizard that follows, choose an appropriate name and disk location for
the workspace. The workspace and project location is not very important, it
can be wherever you want (see Figure A-2).
B
Figure A-2 TORNADO Workspace Setup
6. You may optionally enter a project description.

7. Click Next.
Step 2: Specify VxSim as the BSP to base the project on

1. You have the option of basing the project settings on another project or a BSP.
Select A BSP
2. From the BSP drop down list, select simpc.
3. You should see installDir/target/config/simpc show up in the text box below
the BSP drop down list.
4. Verify the project settings on the next dialog that appears, then click Finish.
31
Tutorial, 4.3
A.2 Customizing the VxWorks Image

Once you have verified that the simulator is available for use with your platform
(or are using another BSP) and have created a new custom bootable project, you
must customize VxWorks to include the necessary runtime components. The
default component configurations differ for each BSP, so your project may or may
not already include some of these components.
A.2.1 About the VxWorks Customizations
The WIND MANAGE WEB SERVER tutorial projects use some features of
VxWorks that are not part of the default VxWorks image for some BSPs. You must
modify your VxWorks image so it includes the following components. Some of
these may already be included in the default image depending on which BSP you
are using. Others, such as the event manager and the WIND MANAGE
WEB SERVER specific zlib implementation are not part of the default for any BSP.
You must ensure that the following components are included in your VxWorks
image configuration.
Network
The default simulator configuration is with network functionality disabled.
The networking subsystem and interface will be added automatically as a
dependency when you include PING, the SNMP agent, or the network show
routines.
DosFs2
The DosFs2 components are required to allow the HTTP server to use ANSI
file systems, such as the WDB target server file system. DosFs2 is required in
all WIND MANAGE WEB SERVER projects that use an ANSI file system.
WDB target server file system
This component is a development tool that allows your target to mount an
ANSI file system on your development host PC. It is required to run the
tutorial projects, but is not a general requirement of WIND MANAGE
WEB SERVER.
Network Debugging > Show Routines
This component is optional. It is useful as a debugging tool, but is not explicitly
required to run the tutorial projects.
PING client
This component is optional. It is useful as a debugging tool, but is not explicitly
required to run the tutorial projects.
32
WindManage SNMP Core Library

This component is optional (however you must build the component binaries
so that certain SNMP header files are available during the tutorial project
compilation). Many of the feature demonstration pages require an SNMP
agent to function properly. You can omit this component if you do not intend
to deploy SNMP on your device, however the related feature demonstration B
pages will not function.
MIB 2 Component MIBs:
– MIB2 ALL
– MIB2 IF
– MIB2 TCP
– MIB2 IP
– MIB2 UDP
– MIB2 SYSTEM
– MIB2 ICMP
A.2.2 Customize VxWorks
Step 1: Add the WDB Target Server File System to the Image
1. In the TORNADO Project facility’s workspace window, click the VxWorks tab.
2. Click the + to expand the bootable project’s VxWorks component selections.
3. Expand
Development Tool Components > WDB Agent Components > WDB Agent Se
rvices.
4. Right-click WDB Target Server File System, and select include.
5. Click OK to confirm the inclusion of this component.
33
Tutorial, 4.3
Step 2: Add DosFs2 to the Image

1. Expand
Operating System Components > IO System Components > dosFs File Syste
m Components (dosFs2).
At this point, if you right-click and include the whole component group
dosFs File System Components (dosFs2), you will be prompted to accept a
default set of components, this default group should include the following
components:
The confirm window indicates that the following dependencies will be
included:
■
CBIO (cached block IO) Support, cbioLib
■
Dos File System Fat12/16/32 Handler
■
DosFs File System Main Module (dosFs2)
■
VFAT directory Handler
If the displayed dependencies do not match the settings listed here, change
them so they do.
2. Click OK to confirm the inclusion of these components.
Step 3: Add Network Show Routines to the Image

1. Expand
Network Components > Networking Protocols > Network Debugging.
2. Include Network show Routines.
Step 4: Add PING to the Image

1. Expand
Network Components > Networking Protocols > Network Applications.
2. Right-click PING client, and select Include ’PING client.’
34
Step 5: Add WIND MANAGE and the MIB2 Components to the Image
1. Expand
Network Components > Networking Protocols > Network Applications > MI
B2 Components > WindManage SNMP Libraries.
2. Right-click WindManage SNMP Core Library, and select B
Include ’WindManage SNMP Core Library.’
Step 6: Configure the SNMP Agent Default System Variables

You must enter default values for the following MIB2 system objects. These values
are used in several of the feature demonstration pages. For further information
about the purpose and data type of each of these OIDs, see the file
installDir/target/src/wrn/wm/snmp/std-mibs/rfc1213.mib.
1. Right-click MIB2 SYSTEM and select Properties of MIB2 SYSTEM.
2. Click the Params tab.
3. Select MIB2SYS_CONTACT and enter a quoted string value for the system
contact. For example: “Mr. Smith”
4. Select MIB2SYS_DESCR and enter a quoted string value for the system
description. For example: “VxWorks 5.5.1 Simulator”
5. Select MIB2SYS_LOCATION and enter a quoted string value for the system’s
physical location. For example: “The Cupboard Under the Stairs, 4 Privet
Drive”
6. Select MIB2SYS_OBJECT_ID and enter a quoted string value for your vendor
device ID. For example: “1.3.6.1.4.1.4242.1.1”
35
Tutorial, 4.3
A.2.3 Build VxWorks
At this point, you have only built a customized VxWorks with the components
needed to run the tutorial. Before you proceed with adding the WIND MANAGE
WEB SERVER files to your project, you should build and test your customized
VxWorks image. Doing this now helps isolate errors should any occur. Before you
build, take a moment to verify that your build settings are correct. In the Project
facility’s workspace window, click the Builds tab. Verify that the default build
matches your target boards’ architecture.
1. Click the + next to the bootable project’s name.
2. Right-click Default and select Properties.
NOTE: You may see other builds available in this window, but generally
default is the one you are after. If it is not set as active, right-click it, and select
Set <build type > as Active Build.
3. Verify that the build settings are correct. Click OK.

4. Once the build settings are verified, right-click Default, and select
Build VxWorks.exe.
NOTE: If you have not generated dependencies yet, TORNADO will prompt
you to do so now. Select (Generate dependencies) for all files then click OK.
The build will proceed when dependency generation is finished.
A.2.4 Boot the Customized VxWorks (VxSim) Image
Before you boot your network enabled VxSim image, you must have the ULIP
adapter installed and configured. For instructions to install and configure ULIP on
your Windows host, see:
■
A.3.1 Installing ULIP on Windows XP, p.40
■
A.3.2 Installing ULIP on Windows 2000, p.41
■
A.3.3 Installing ULIP on Windows NT 4.0, p.43
Verify that this VxWorks image boots and runs properly. Booting the simulator
attached to the correct target server is a bit tricky, so follow the instructions in this
section carefully. If you are using a real target, be sure your target boot parameters
point to the VxWorks image you created for this project and boot your target.
36
Step 1: Boot VxWorks (VxSim).

1. Click the VxSim icon in the TORNADO tool bar.
2. In the VxSim Launch: Select Image and Options dialog box, select
Custom-built simulator, then click Browse.
B
3. Navigate to the custom configured VxWorks image you built in A.1.1 Create the
Workspace and Custom Bootable Project, p.30. The VxWorks executable should be
yourProjFolder/default/VxWorks.exe. Click Select.
4. Leave Processor no.: (0-9) at 0. Click OK.
5. Selecting 0 gives your vxsim image an IP address of 90.0.0.1, selecting 1 will
give your vxsim image an IP address of 90.0.0.2, and so on.
6. A VxWorks Simulator for Windows window appears with the following
information:
Attached TCP/IP interface to nt unit 0
Attaching interface lo0 . . . done
! WARNING: Do not click OK after this step. TORNADO will tell you that a target
server is required and one will be started for you. In the
VxSim Launch: Launch Target Server, click Cancel. You need to use a target
server with some more useful configuration settings.
7. Click Cancel. You need to use a target server with appropriate configuration
settings.
A.2.5 WDB Target Server Setup
The TORNADO Project facility has a mechanism to communicate with your target
board during the development process—the WDB target sever. There is more than
one way to configure the TORNADO target server, and a discussion of each is
beyond the scope of this tutorial. So for the sake of this tutorial, we will use the
following method.
Step 1: Create the target server.

1. In TORNADO, click the Tools menu, and select Target Server > Configure.
2. In the dialog that follows, click New, and choose a suitable name for your
target and, optionally, a description.
37
Tutorial, 4.3
Step 2: Set the back-end type.

1. In the Target Server Properties menu, select Back End.
2. In the Available Back Ends list, select wdbrpc.
3. Enter reasonable values for connection time-out and number of retries.
Step 3: Specify the core VxWorks file and symbol tables.

1. In the Target Server Properties menu, select Core File and Symbols.
2. If your target boot parameters include a path to a VxWorks image on your
host, select File Path from Target (if available), otherwise, select File, and
enter the path the VxWorks image you created in step A.2.3 Build VxWorks,
p.36.
3. Select Global Symbols.
Step 4: Enable console IO redirection.

1. In the Target Server Properties menu, select Console and Redirection.
2. Click Redirect Target IO. This allows you to view console IO on the
TORNADO host based shell (WindSh).
Step 5: Set the file system root for the target server file system.
1. Still in the Target Server Properties menu, check Enable File System.
2. Then enter the actual value of your installation directory (installDir) as the host
path to the file system root, and select Read/Write.
Default values for the remaining target server configuration options should
suffice. For more information on the target server and its use, see the VxWorks
Programmer’s Guide, 5.5.
Step 6: Set the Target IP Address and Launch the Target Server
1. In the Target Name/IP Address field, enter 90.0.0.1 (or the IP address /NIS
name of your actual target if you are using one).
38
2. Click Launch.
The connection to the target server will occur mostly in the background. You
should verify that the target server has successfully attached to the VxSim
image by double clicking the target server icon in the tools tray at the bottom
of your screen.
B
In the target log console, you should messages similar to the following:
tgtsvr (VxTarget1@c-81093): Mon Oct 01 11:47:46 2001
Wind River Systems Target Server: NT/Win95 version
Connecting to target agent... succeeded.
Attaching C++ interface... succeeded.
Attaching pecoff OMF reader for SIMNT CPU family... succeeded.
3. Click Hide to dismiss this window and leave the target server running.
A.2.6 Launch a Shell and Verify the Connection
In TORNADO, select Tools > Shell. Select your target from the list and click OK.
In the host shell (or console output window) you should see the typical VxWorks
startup banner. You can also verify that the WDB target server file system is
running properly by typing devs at the shell prompt. The response should include
the device /tgtsvr —which is part of the newly built VxWorks image— as well as
some other system devices.
Troubleshooting
If the shell does not launch, check the target server you configured to verify that it
was configured properly and that it launched. Boot time checksum errors can
occur if the target server boot image path specifies a different VxWorks image than
the target’s boot parameters. If the target boot parameters specify a VxWorks
image, be sure that image is in the correct path, it has the correct features built in,
and ensure the target server Core File and Symbols properties specify
Get File form Target.
Build errors can occur if the DosFs2 object modules do not load properly. This more
is likely to be the case if you are using a version of TORNADO prior to 2.2, and
dosFs2 was installed after TORNADO. If you see errors similar to the following:
partialImage.o: In function `dosVDirLibInit':
partialImage.o(.text+0x7349a): undefined reference to `dosDirHdlrsList'
partialImage.o(.text+0x7349e): undefined reference to `dosDirHdlrsList'
partialImage.o(.text+0x734a4): undefined reference to `dosFsHdlrInstall'
39
Tutorial, 4.3
You may need to install dosFs2, or run the dosFs2 patch. This patch copies the
appropriate DosFs2 object modules into the DosFs2 libraries. You can get this
patch from the Wind River Support site) http://www.windriver.com/support/.
Search for SPR# 64615.
Be sure that you configured the simulator to use networking, and that you created
the bootable project after enabling the simulator for networking.
A.3 Installing the ULIP Virtual Adapter

In order to simulate the network IP connectivity of a VxWorks target, VxSim
includes special drivers which operate using IP addresses. The User-Level Internet
Protocol (ULIP) driver allows VxWorks to talk to other machines by handing off IP
packets to the host Operating System for processing. The ULIP driver is
automatically initialized by VxSim.
A.3.1 Installing ULIP on Windows XP
In order to simulate the network IP connectivity of a VxWorks target, VxSim

includes special drivers which operate using IP addresses. The User-Level Internet
Protocol (ULIP) driver allows VxWorks to talk to other machines by handing off IP
packets to the host Operating System for processing. The ULIP driver is
automatically initialized by VxSim.
Step 1: Install the ULIP Virtual Adapter Driver

1. From the Start menu, select Settings > Control Panel > Add Hardware.
2. In the Add Hardware wizard, click Next. Windows will scan for hardware
changes.
3. Select Yes, I have already connected this hardware, then click Next.
4. Select Add a new hardware device, then click Next.
5. Select Install the hardware that I manually select from a list (advanced), then
click Next.
6. Select Network Adapters, then click Next.
7. Click Have Disk.
40
8. Click Browse and navigate to installDir/host/x86-win32/bin, select

oemsetup.inf, then click Open to select this driver information file.
9. Click OK.
10. Select WindRiver ULIP in the hardware list, then click Next.
B
NOTE: The ULIP driver is not digitally signed.
11. Windows will prompt you that this driver has not passed Windows Logo
testing. Click Continue anyway.
12. You will see a similar message for the Deterministic network enhancer
miniport. Click Continue anyway.
13. Click Finish.
Step 2: Configure the ULIP Adapter

After the final step above, you must configure the ULIP virtual adapter.
1. Select Control Panel > Network Connections.
2. Click WindRiver ULIP, then click Change settings of this connection.
3. Select Internet Protocol (TCP/IP), then click Properties.
4. Click Use the following IP address, then enter the following
a. Enter 90.0.0.254 in the IP Address field.
90.0.0.254 is the virtual gateway for the VxSim agent.
b. Enter 255.255.255.0 in the Subnet Mask field.
c. Leave Default Gateway blank.
d. Leave the DNS address fields blank.
5. Click OK, then restart your computer if necessary.
A.3.2 Installing ULIP on Windows 2000

1. From the Start menu, select Settings > Control Panel > Add Hardware.
2. In the Add/Remove Hardware wizard, click Next.
41
Tutorial, 4.3
3. Select Add/Troubleshoot a device, then click Next. Windows will scan for
hardware changes.
4. Select Add a new device, then click Next.
5. Select No, I want to select the hardware from a list, then click Next.
6. Select Network Adapters, then click Next.
7. Click Have Disk.
8. Click Browse and navigate to installDir/host/x86-win32/bin, select
oemsetup.inf, then click Open to select this driver information file.
9. Click OK.
10. Select WindRiver ULIP in the hardware list, then click Next.
NOTE: The ULIP driver is not digitally signed.
11. Windows will prompt you that this driver is not digitally signed. Click Next.
12. Click Finish.
Step 2: Configure the ULIP Adapter

After the final step above, you must configure the ULIP virtual adapter.
1. Select Control Panel > Network Connections.
2. Click WindRiver ULIP, then click Change settings of this connection.
3. Select Internet Protocol (TCP/IP), then click Properties.
4. Click Use the following IP address, then enter the following
a. Enter 90.0.0.254 in the IP Address field.
90.0.0.254 is the virtual gateway for the VxSim agent.
b. Enter 255.255.255.0 in the Subnet Mask field.
c. Leave Default Gateway blank.
d. Leave the DNS address fields blank.
5. Click OK, then restart your computer if necessary.
42
A.3.3 Installing ULIP on Windows NT 4.0

1. From the Start menu, select Settings > Control Panel > Network.
2. Select the Adapters tab. B
3. Click Add.
4. Click Have Disk.
5. Type the path name, installDir/host/x86-win32/bin, in the text area, then click
OK.
6. In the Select OEM Option window ULIP Virtual Adapter will be in the select
list. Select it, then click OK.
7. Click Close.
Windows will update the network bindings.
Step 2: Configure the ULIP Virtual Adapter Driver

After the final step above, the TCP/IP Properties window should appear. (If
not, select Network > Protocols, then double click on TCP/IP Protocol)
1. Select ULIP Virtual Adapter in the Adapter: drop down list.
2. Select Specify an IP address.
3. Type 90.0.0.254 in the IP Address field.
90.0.0.254 will actually be the virtual gateway for the VxSim agent.
4. Type 255.255.255.0 in the Subnet Mask field.
5. Leave Default Gateway blank, then click Apply.
6. Select the Routing tab.
43
Tutorial, 4.3
7. If Enable IP Forwarding is not checked, select it then click Apply.

8. Select the WINS Address tab.
9. If Enable DNS for Windows Resolution is not checked, select it, then click
Apply.
10. Click Yes on the warning about the adapter card having an empty primary
WINS address.
11. Click OK, then restart your computer.
44
Index
B E
bootable embedded HTTP server
project, VxWorks 40 generated configuration files 5
booting the VxWorks simulator 37 endian 5
BSP 4
VxWorks simulator 31
build specification
VxWorks simulator 3 F
file system
WDB Target Server 38
C WDB target server 32
WDB target server, setup 38
configuring ULIP 41, 42, 43
console IO redirection 38
core VxWorks file 38
creating, TORNADO tutorial workspace 30 G
generated
code
D overview 4
files
dosFs2 embedded HTTP server configuration 5
adding to VxWorks image 34
VxWorks component 32, 40
downloadable projects
tornado 3 H
host shell 39
45
Tutorial, 4.3
I symbol tables, target server setup 38
installation directory, WIND MANAGE 3

installing ULIP on the host 40, 41, 43 T
target
L generated source code 4
Target Server file system, see WDB Target Server file
launching the VxWorks simulator 37 system
TORNADO
workspace
creating 30
N tutorial
outline 2
network show routines
VxWorks component 32
networking U
configuring the VxWorks simulator 40
ULIP
configuring 41, 42, 43
installing on the host 40, 41, 43
O using with VxWorks simulator 29
underscores, in file names 5
outline, tutorial 2
overview
generated code 4
V
VxSim, see VxWorks simulator
P VxWorks
adding components to image 33
patch, dosFs2 40 bootable project 40
PING client building the tutorial image 36
adding to VxWorks image 34 component
project dosFs2 32
downloadable, Tornado 3 network show routines 32
WDB Target Server file system 32
simulator 2, 3
booting 37
S BSP 31
build specification 3
settings
configuring for networking 40
VxWorks simulator target server 37
configuring for the tutorial 32
simpc, see VxWorks simulator
core file 38
simulator see VxWorks simulator
full version, confirming 30
46
Index
target server settings 37

using with ULIP 29
versions required 3
VxWorks components
dosFs2 32, 40
network show routines 32
Index
WDB Target Server File System 32
W
WDB Target Server file system 32, 38
WIND MANAGE
installation directory 3
Integration Tool, see WMIT
WMIT 2
wmw_httpconf.c, overview 5
47

Windmanage Cli Tutorial 4.3

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Windmanage Cli Tutorial 4.3

Transféré par

Droits d'auteur :

Formats disponibles

4.

toll free (U.S.): (800) 545-WIND

WIND MANAGE COMMAND LINE INTERFACE Tutorial, 4.3

1 Getting Started ..................................................................................... 1

1.1 Introduction ............................................................................................................. 1

1.2 Tutorial Overview and Outline ........................................................................... 2

1.3 What You Need Before Starting ........................................................................... 3

1.4 Generated Code Overview ................................................................................... 4

2 Creating A Basic Command Line Interface ....................................... 7

2.1 Scalar GETs and SETs ............................................................................................ 7

Sample Device Data ................................................................................. 8

2.2 Access Control ......................................................................................................... 19

A Setting up VxWorks, VxSim, and ULIP ............................................... 29

A.1 Creating a Custom Bootable VxWorks or VxSim Project ............................... 29

A.2 Customizing the VxWorks Image ....................................................................... 32

A.2.5 WDB Target Server Setup ........................................................................ 37

A.3 Installing the ULIP Virtual Adapter ................................................................... 40

1.2 Tutorial Overview and Outline

Project 02—Access Control 1

1.3 What You Need Before Starting

1.3.1 The Tornado IDE

1.3.2 A Customized VxWorks Bootable Image

1.3.3 WIND MANAGE CLI

VxSim and BSP Issues

Every Tornado project file contains architecture/BSP specific information. Each

Avoiding Telnet Conflicts

WIND MANAGE CLI implements a telnet daemon. VxWorks also implements a

1.4 Generated Code Overview

CLI Engine Configuration and Command Files

The embedded CLI engine configuration files, wmc_projName.c/h and

Global Configuration File

Backplane Configuration Files

The backplane configuration file, wmb_options.h, contains configuration settings

Backplane Project Files

2.1 Scalar GETs and SETs 7

2.1 Scalar GETs and SETs

2.1.1 Configure the WIND MANAGE CLI Project

Create the Tutorial 01 WIND MANAGE Integration Tool project.

Sample Device Data

Set the WIND MANAGE Integration Tool Global Options

These options apply to all of the components in a WIND MANAGE project. In

b. In the left pane of this window, select Directories. 2

Configuring the Backplane and the Component Interface

This defines the RCC_TASK_ValidateLogin( )—the sample

2.1.2 Create the WindMarks 2

2. Create the sysName WindMark.

2.1.3 Create the CLI Commands 2

1. Create the Show node.

d. Uncheck Enable Intermediate Mode for this node.

d. Uncheck Enable Intermediate Mode for this node. 2

a. Repeat step 7 above for set sysDescr using val_sysDescr as the

2.1.4 Generate the Files

2.1.5 Create the Tornado Project File

NOTE: It is possible to install WIND MANAGE outside the Tornado tree. If 2

2. If WIND MANAGE is not installed in the same installation location as

2.1.6 Build the WIND MANAGE CLI Application

c. Right-click tutorial01 and select Build tutorial01.out.

2.1.7 Run the WIND MANAGE CLI Application

1. Connect to the embedded telnet server.

2.2 Access Control

Types of Access Control

There are three types of access control in WIND MANAGE CLI.

2.2.1 Configure the WIND MANAGE CLI Project

Assign Access Levels to Commands