Professional Documents
Culture Documents
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.
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
8 Sep 04
Part #: DOC-15247-ZD-00
Contents
iii
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
iv
Contents
Index .............................................................................................................. 45
v
WIND MANAGE COMMAND LINE INTERFACE
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
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
2
1 Getting Started
1.3 What You Need Before Starting
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).
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.
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.
3
WIND MANAGE COMMAND LINE INTERFACE
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.
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.
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.
5
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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
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
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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.
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.
8
2 Creating A Basic Command Line Interface
2.1 Scalar GETs and SETs
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.
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
WIND MANAGE COMMAND LINE INTERFACE
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
10
2 Creating A Basic Command Line Interface
2.1 Scalar GETs and SETs
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
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
12
2 Creating A Basic Command Line Interface
2.1 Scalar GETs and SETs
13
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
14
2 Creating A Basic Command Line Interface
2.1 Scalar GETs and SETs
15
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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.
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
2 Creating A Basic Command Line Interface
2.1 Scalar GETs and SETs
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.
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
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
18
2 Creating A Basic Command Line Interface
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.
19
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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 Creating A Basic Command Line Interface
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.
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
WIND MANAGE COMMAND LINE INTERFACE
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.
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 Creating A Basic Command Line Interface
2.2 Access Control
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.
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
WIND MANAGE COMMAND LINE INTERFACE
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).
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 Creating A Basic Command Line Interface
2.2 Access Control
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
WIND MANAGE COMMAND LINE INTERFACE
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.
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
already be in the set-> intermediate mode.
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 Creating A Basic Command Line Interface
2.2 Access Control
27
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
28
A
Setting up VxWorks, VxSim,
and ULIP
29
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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.
30
A Setting up VxWorks, VxSim, and ULIP
A.1 Creating a Custom Bootable VxWorks or VxSim Project
31
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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
A Setting up VxWorks, VxSim, and ULIP
A.2 Customizing the VxWorks Image
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
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
34
A Setting up VxWorks, VxSim, and ULIP
A.2 Customizing the VxWorks Image
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.’
3. Click OK to confirm the inclusion of this component.
35
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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.
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.
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
A Setting up VxWorks, VxSim, and ULIP
A.2 Customizing the VxWorks Image
! 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.
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.
37
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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
A Setting up VxWorks, VxSim, and ULIP
A.2 Customizing the VxWorks Image
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.
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
WIND MANAGE COMMAND LINE INTERFACE
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.
40
A Setting up VxWorks, VxSim, and ULIP
A.3 Installing the ULIP Virtual Adapter
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.
41
WIND MANAGE COMMAND LINE INTERFACE
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.
11. Windows will prompt you that this driver is not digitally signed. Click Next.
12. Click Finish.
42
A Setting up VxWorks, VxSim, and ULIP
A.3 Installing the ULIP Virtual Adapter
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.
43
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
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
WIND MANAGE COMMAND LINE INTERFACE
Tutorial, 4.3
46
Index
W
WDB Target Server file system 32, 38
adding to VxWorks image 33
WIND MANAGE
installation directory 3
Integration Tool, see WMIT
WMIT 2
wmw_httpconf.c, overview 5
47