![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
|
|||||||||||||||||||
You do not need much of this chapter if all you want to do is connect to a target that is already set up on your network. If this is the case, read 2.2 Setting Up the Host and then proceed with 2.5 Booting VxWorks.
|
|
|||||||||||||||||||
Tornado host tools such as the shell and the debugger communicate with the target system through a target server. A target server can be configured with a variety of back ends, which provide for various modes of communication with the target agent. On the target side, VxWorks can be configured and built with a variety of target agent communication interfaces.
Your choice of target server back end and target agent communication interface is based on the mode of communication that you establish between the host and target (network, serial, and so on). In any case, the target server must be configured with a back end that matches the target agent interface with which VxWorks has been configured and built. See Figure 2-1 for a detailed diagram of host-target communications.
All of the standard target server back ends included with Tornado connect to the target through the target agent. Thus, in order to understand the features of each back end, you must understand the modes in which the target agent can execute. These modes are called task mode, system mode, and dual mode.
The most common VxWorks communication path--both for server-agent communications during development, and for applications--is IP networking over Ethernet. That connection method provides a very high bandwidth, as well as all the advantages of a network connection.
Nevertheless, there are situations where you may wish to use a non-network connection, such as a serial line or a ROM-emulator connection. For example, if you have a memory-constrained application that does not require networking, you may wish to remove the VxWorks network code from the target system during development. Also, if you wish to perform system-mode debugging, you need a communication path that can work in polled mode. Older versions of VxWorks network interface drivers such at netif do not support polled operations and so cannot be used as a connection for system-mode debugging.
Note that the target-server back end connection is not always the same as the connection used to load the VxWorks image into target memory. For example, you can boot VxWorks over Ethernet, but use a serial line connection to exploit a polled-mode serial driver for system-mode debugging. You can also use a non-default method of getting the run-time system itself into your target board. For example, you might burn your VxWorks run-time system directly into target ROM, as described in VxWorks Programmer's Guide: Configuration and Build. Alternatively, you can use a ROM emulator such as NetROM to quickly download new VxWorks images to the target's ROM sockets. Another possibility is to boot from a disk locally attached to the target; see the VxWorks Programmer's Guide: Local File Systems. You can also boot from a host disk over a serial connection using the Target Server File System; see 2.5.7 Booting a Target Without a Network.Certain BSPs may provide other alternatives, such as flash memory; see the reference information for your BSP.
The Tornado target server registry is a service that keeps track of target servers and provides your host with access to them. The registry1 must always be running; otherwise Tornado tools cannot communicate with targets. Because Tornado development tools are independent of the method of communication with the target, the registry is required regardless of whether the target communicates over a network or serial links.
The Tornado registry need not run on the same host as your tools, as long as it is accessible on the network. In fact, it is recommended that a development site use a single registry for the entire network; this provides maximum flexibility, allowing any Tornado user at the site to connect to any target.
If you attempt to start a registry when one is already running on the same host, the new registry automatically detects that it is not needed. It displays the Tornado Registry window with a warning message, and then shuts itself down when you click the associated OK button.
When the Tornado registry is running on your host system, the registry icon is displayed in the Windows taskbar (except when the registry is running as a Windows service). The pop-up menu for the icon provides options for displaying the window, displaying version information about the registry, and shutting down the registry. Double-click on the icon to display the Tornado Registry window (Figure 2-2).
The Tornado Registry window displays log information and a list of all the target servers that have been registered with it, including information about the target system and the user. The Hide button hides the Tornado Registry window. The Kill Registry button shuts down the registry. The About button displays version information for the registry. The Refresh button refreshes information about the entries in the registry.
Your usage of the Tornado registry is initially determined during the software installation process, based on the installer's choice of options for the registry. See the Tornado Getting Started Guide for information about installation.
After installation you can select to use a different Tornado registry with the Tornado Registry page of the Options window (Tools>Options>Tornado Registry).
If you did not set up the registry as a Windows service when you installed Tornado with the SETUP program, you can use a Tornado service utility to do so (see E. Windows NT Service Manager).
For detailed information about the operation of the Tornado registry, and its command options, see the wtxregd reference page in the online Tornado API Reference.
The following steps refer to configuration choices that are required during Windows TCP/IP installation:
|
|
NOTE:
If your machine is not networked, the Tornado services must all run locally; make sure that the registry is running on your system (see Tornado Registry).
|
||||||||||||||||||
If you plan to use the Tornado tools from the UI all system variables are set during installation. However, if you plan to use the command line you will need to set some variables by hand. The easiest way is to go to the bin directory and execute torVars.bat.
c:>\ cd installDir/host/x86-win32/bin c:>\ torVars.bat
This section covers bringing up VxWorks on a hardware target with the relatively simple configuration matching the default software image. In the next section, 2.4 Host-Target Communication Configuration, additional options are discussed. The VxWorks Programmer's Guide and the VxWorks Network Programmer's Guide elaborate on more advanced options, such as gateways, NFS, multiprocessor target systems, and so on.
|
|
|||||||||||||||||||
VxWorks is a flexible system that has been ported to many different hardware platforms. The default VxWorks run-time development configuration is shown in Figure 2-3. The pre-built VxWorks images shipped with your BSP include all the necessary components to run on this hardware configuration.
The configuration in Figure 2-3 consists of the following:
IP networking over Ethernet is the most desirable way to connect a development target to your host, because of the high bandwidth it provides. This section describes setting up simple IP connections to a target over Ethernet. To read about other communication strategies, see 2.4 Host-Target Communication Configuration.
Before VxWorks can boot an executable image obtained from the host, the network software on the host must be correctly configured. There are three main tasks in configuring the host network software for VxWorks:
The TCP/IP networking package should already be installed on the Windows host where you are configuring Tornado; TCP/IP is generally installed when the operating system is first installed. If TCP/IP is not yet installed on your Tornado host, install it now. Consult your Windows documentation on installing and configuring TCP/IP for your PC. For appropriate settings, see TCP/IP.
To use the default VxWorks configuration and boot VxWorks over the network, you must have an FTP server running on the host where the VxWorks system image is stored, and the FTP server must have a user ID and password defined that your VxWorks target can use to identify itself.
Tornado includes an FTP-server application, wftpd32.exe. See F. FTP Server for information on configuring this FTP server. We recommend that you install the FTP server as an NT service when you install TCP/IP.
With TCP/IP installed, you can configure the server that provides Domain Name Service (DNS) so that your Windows computer uses that server to translate system names to network IP addresses. Consult your Windows documentation on how to configure your system to take advantage of DNS.
If you do not have a domain name server at your site, you can specify how to map machine names to IP addresses in a file called hosts on your machine. Otherwise, you must identify targets by IP address.
The hosts file records the names and IP network addresses of systems accessible on the network from the local system. The location of this file depends on which version of Windows you use:
Each line consists of an IP address and the name (or names) of the system at that address.
For example, suppose your host system is called mars and has Internet address 90.0.0.1, and you want to name your VxWorks target phobos and assign it address 90.0.0.50. The hosts file must then contain the following lines:
90.0.0.1 mars 90.0.0.50 phobos
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
In every case, you will need to create your own boot medium. Your board will require one of the following media:
For specific information on a BSP's booting method, see Help>Manuals Contents>BSP Reference. Instructions for making a floppy disk for booting a Pentium target are in the VxWorks for Pentium Architecture Supplement.
You may also wish to replace a boot ROM, even if it is available, with a ROM emulator. This is particularly desirable if your target has no Ethernet capability, because the ROM emulator can be used to provide connectivity at near-Ethernet speeds. Tornado includes support for one such device, NetROM.2 For information about how to use NetROM on your target, refer to Configuration for NetROM Connection. Contact the nearest Wind River office (see copyright page) for information about support for other ROM emulators.
For cases where boot ROMs are used to boot VxWorks, install the appropriate set of boot ROMs on your target board(s). When installing boot ROMs, be careful to:
See 4.8 Configuring and Building a VxWorks Boot Program for instructions on creating a new boot program with parameters customized for your site.
Many CPU and Ethernet controller boards still have configuration options that are selected by hardware jumpers, although this is less common than in the past. These jumpers must be installed correctly before VxWorks can boot successfully. You can determine the correct jumper configuration for your target CPU from the information provided in the target-information reference for your BSP (see Help>Manuals>BSP Reference in the Tornado IDE or the file c:\tornado\docs\BSP_Reference.html).
For bare-board targets, use the power supply recommended by the board manufacturer.
If you are using a VME chassis, install the CPU board in the first slot of the backplane (Figure 2-4). If you are using a separate Ethernet controller board, install it in the second slot of the backplane.
Most VxWorks targets include at least one on-board serial port. This serial port must be connected to a terminal emulator (HyperTerminal) to use the default configuration. After initial configuration of the boot parameters and getting started with VxWorks, you may wish to configure VxWorks to boot automatically without a terminal. Refer to the CPU board hardware documentation for proper connection of the RS-232 signals.
Tornado comes with terminal-emulator software already configured for connecting to VxWorks targets on either COM1 or COM2; the software is in the same program folder as other Tornado programs. Use VxWorks COM1 if the serial connection from your target is to COM1, or VxWorks COM2 if the target is connected to COM2.
Connecting the target server to the target in a configuration other than the default requires a little work on both the host and target. The next few subsections describe the details for network connections, END connections, serial line connections, the NetROM Emulator, and the transparent mode driver.
A network connection is the easiest to set up and use, because most VxWorks targets already use the network (for example, to boot); thus, no additional target set-up is required. Furthermore, a network interface is typically a board's fastest physical communication channel.
When VxWorks is configured and built with a network interface for the target agent (the default configuration), the target server can connect to the target agent using the default wdbpipe back end (see 8.2 Configuring and Starting a Target Server).
The target agent can receive requests over any device for which a VxWorks network interface driver is installed. The typical case is to use the device from which the target was booted; however, any device can be used by specifying its IP address to the target server.
The default VxWorks system image is configured for a networked target. See 4.7 Configuring the Target-Host Communication Interface for information about configuring VxWorks for various target agent communications interfaces.
See Configuration for an END Driver Connection for information about configuring the VxWorks target agent for an END connection.
Figure 2-5 illustrates a minimal cross-development configuration: the target is a bare board, connected to the host development system by a single serial line. For a configuration of this sort, use a combination of a boot mechanism that does not require a network and an alternative Tornado communications back end.
Tornado can operate over a raw serial connection between the host and target systems, and can operate on standalone systems that have no network connection to other hosts.
When you connect the host and target exclusively over serial lines, you must:
For more information, see 4.7 Configuring the Target-Host Communication Interface.
A raw serial connection has some advantages over an IP connection. The raw serial connection allows you to scale down the VxWorks system (even during development) for memory-constrained applications that do not require networking: you can remove the VxWorks network code from the target system.
When working over a serial link, use the fastest possible line speed. The Tornado tools--especially the browser and the debugger--make it easy to set up system snapshots that are periodically refreshed. Refreshing such snapshots requires continuing traffic between host and target. On a serial connection, the line speed can be a bottleneck in this situation. If your Tornado tools seem unresponsive over a serial connection, try turning off periodic updates in the browser, or else closing any debugger displays you can spare.
To configure the target agent for a raw serial communication connection, reconfigure and rebuild VxWorks with a serial communication interface for the target agent (see Configuration for Serial Connection).
When you connect the host and target exclusively over serial lines, you must configure and build a boot program for the serial connection because the default boot configuration uses an FTP download from the host (see 4.8 Configuring and Building a VxWorks Boot Program). The simplest way to boot over a serial connection is by using the Target Server File System. See 2.5.7 Booting a Target Without a Network.
Be sure to use the right kind of cable to connect your host and target. Use a simple Tx/Tx/GND serial cable because the host serial port is configured not to use handshaking. Many targets require a null-modem cable; consult the target-board documentation. Configure your host-system serial port for a full-duplex (no local echo), 8-bit connection with one stop bit and no parity bit. The line speed must match whatever is configured into your target agent.
Before trying to attach the target server for the first time, test that the serial connection to the target is good. To help verify the connection, the target agent sends the following message over the serial line when it boots (with WDB_COMM_SERIAL):
WDB READY
To test the connection, attach a terminal emulator to the target-agent serial port, then reset the target (see Connecting a Serial Cable for the Terminal Emulator). If the WDB READY message does not appear, or if it is garbled, check the configuration of the serial port you are using on your host.
As a further debugging aid, you can also configure the serial-mode target agent to echo all characters it receives over the serial line. This is not the default configuration, because as a side effect it stops the boot process until a target server is attached. If you need this configuration in order to set up your host serial port, edit target\src\config\usrWdb.c.
#ifdef INCLUDE_WDB_TTY_TEST
/* test in polled mode if the kernel hasn't started */
if (taskIdCurrent == 0)
wdbSioTest (pSioChan, SIO_MODE_POLL, 0);
else
wdbSioTest (pSioChan, SIO_MODE_INT, 0);
#endif /* INCLUDE_WDB_TTY_TEST */
In both calls to wdbSioTest( ), change the last argument from 0 to 0300.
With this configuration, attach any terminal emulator on the host to the COM port connected to the target to verify the serial connection. When the serial-line settings are correct, whatever you type to the target is echoed as you type it.
|
|||||||||||||||||||
After successfully testing the serial connection, you can connect the target server to the agent by following these steps:
C:\> tgtsvr -V targetname -d com1 -B wdbserial -bps 38400
You can also use the Tornado GUI to configure and start a target server (see 8.2 Configuring and Starting a Target Server).
The agent can be configured to communicate with the target server using the target board's ROM socket. Tornado supports this configuration for NetROM, a ROM emulator produced by Applied Microsystems Corporation. Contact your nearest Wind River office (listed on the back cover) for information about support for other ROM emulators. Figure 2-6 illustrates this connection method.
The NetROM acts as a liaison between the host and target. It communicates with the host over Ethernet, and with the target through ROM emulation pods that are plugged into the target board's ROM sockets. The NetROM allows you to download new ROM images to the target quickly. In addition, a 2 KB segment of the NetROM's emulation pod is dual-port RAM, which can be used as a communication path. The target agent uses the NetROM's read-only protocol to transfer data up to the host. It works correctly even on boards that do not support write access to the ROM banks.
This communication path has many benefits: it provides a connection which does not intrude on any of your board's I/O ports, it supports both task-mode and system-mode debugging, it is faster than a serial-line connection, and it provides an effective way to download new VxWorks images to the target.
For information about booting a target without a network, see 2.5.7 Booting a Target Without a Network.
To configure the target agent for a NetROM communication connection, reconfigure and rebuild VxWorks with a NetROM interface for the target agent. Several configuration macros are used to describe a board's memory interface to its ROM banks. You may need to override some of them for your board. See Configuration for NetROM Connection.
Before a target server on your host can connect to the target agent over NetROM, some hardware and software configuration is necessary. The following steps outline this process.
When it powers up, the NetROM knows its own Ethernet address, but does not know its internet (IP) address.
There are two ways of establishing an IP address for the NetROM:
After the NetROM obtains its IP address, it loads a startup file. The pathname for this file depends on which protocol establishes the IP address:
The startup file contains NetROM commands describing the emulated ROM, the object format, path and file names to download, and so on. The following example NetROM startup file configures the Ethernet device, adds routing information, records the object-file name to download and the path to it, and establishes ROM characteristics.
Example 2-1: Sample NetROM Startup File
begin
ifconfig le0 147.11.46.164 netmask 255.255.255.0 broadcast 147.11.46.0
setenv filetype srecord
setenv loadpath c:\tftpboot
setenv loadfile vxWorks_rom.hex
setenv romtype 27c020
setenv romcount 1
setenv wordsize 8
setenv debugpath readaddr
set udpsrcmode on
tgtreset
end
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Once the required NetROM address and boot information is configured on a host, the NetROM can be powered up. To verify that the NetROM has obtained its IP address and loaded and executed the startup file, you can connect to a NetROM command line with a telnet session.
The NetROM begins a telnet connection with the following prompt:
NETROM TELNET NetROM>
At the NetROM prompt, you can display the current configuration by entering the command printenv to verify that the startup file executed properly.
One method is to type the newimage command at the NetROM prompt. This command uses the TFTP protocol to download the image specified by the loadfile environment variable from the path specified by the loadpath environment variable (which is c:\tftpboot\vxWorks_rom.hex if you use the startup script in Example 2-1). After the NetROM configuration is stable, you can include this command in the startup file to download the image automatically. Wait to be certain the image is completely downloaded before you power up your target. This method takes about 30 seconds to transfer the image.
A faster method is to use the download.exe utility from AMC (see the AMC NetROM documentation).
Start the target server as in the following example, using the -B option to specify the NetROM back end.
C:\> tgtsvr -V 90.0.0.5 -B netrom
In this example, 90.0.0.5 is the IP address of the NetROM. (You can also use the Tornado GUI to configure and start a target server; see 8.2 Configuring and Starting a Target Server.)
If the connection fails, try typing the following command at the NetROM prompt:
NetROM> set debugecho on
With this setting, all packets sent to and from the NetROM are copied to the console. You may need to hook up a connector to the NetROM serial console to see the debugecho output, even if your current console with NetROM is attached through Telnet (later versions of NetROM software may not have this problem). If you see packets sent from the host, but no reply from the target, you must modify the target NetROM configuration parameters described in section Configuring the Target Agent for NetROM.
|
|
NOTE:
With a NetROM connection, you must inform the NetROM when you reboot the target. You can do this as follows at the NetROM prompt:
NetROM> tgtreset |
||||||||||||||||||
It is possible that the NetROM is not correctly configured for downloading code to the target. Make sure you can download and run a simple piece of code (for example, to blink an LED -- this code should be something simpler than a complete VxWorks image).
If you can download code and execute it, the next possibility is that the board initialization code is failing. In this case, it never reaches the point of trying to use the NetROM for communication. The code in target/src/config/usrWdb.c makes a call to wdbNetromPktDevInit( ). If the startup code does not get to this point, the problem probably lies in the BSP. Contact the vendor that supplied the BSP for further troubleshooting tips.
|
|
|||||||||||||||||||
When you rerun VxWorks with this modification, the wdbNetromPktDevInit( ) routine attempts to print a message to NetROM debug port. The initialization code halts until you connect to the debug port (1235), which you can do by typing:
% telnet NetROM_IPaddress 1235
If the debug port successfully connects, the following message is displayed in the telnet window:
WDB NetROM communication ready
If you do not see this message, the NetROM dual-port RAM has not been configured correctly. Turn off the processor cache; if that does not solve the problem, contact AMC for further trouble shooting tips:
If everything has worked up to this point, reset wdbNetromTest back to zero and end your telnet session.
Type the following at the NetROM prompt:
NetROM> set debugecho on
This causes data to be echoed to the NetROM console when packets are transmitted between the host and target. If you have a VxWorks console available on your target, edit wdbNetromPktDrv.c by changing the following line:
int wdbNetromDebug = 0;
int wdbNetromDebug = 1;
This causes messages to be echoed to the VxWorks console when packets are transmitted between the host and target.
|
|
|||||||||||||||||||
At this point, you have debugging output on three levels: the target server is recording all transactions between it and the NetROM box; the NetROM box is printing all packets it sees to its console; and the WDB agent is printing all packets it sees to the VxWorks console. If this process does not provide enough debug information to resolve your problems, contact Wind River technical support for more troubleshooting assistance.
The TM driver provides the same connection capability as an Ethernet or serial cable would. However, the TM driver works through the Wind River visionICE II/visionPROBE II hardware debug tools. Physically, the connection is implemented over the BDM/JTAG/EJTAG emulation connection provided by the tools. This can be advantageous if the target being used does not have an Ethernet or serial port on it, or if the ports are required for something else. It can also be useful when the target ports are available, but the software that controls them is not yet working.
The Wind River TM driver supports both system and task level debugging. The TM driver also supports the /vio (virtual I/O) sub-channel of the WDB protocol.
The TMD is added to the current build by selecting the VxWorks tab in the project dialog window. Expand the VxWorks entry associated with your project, and from the list that appears, select development tool components>select WDB connection>WDB visionTMD connection.
For the TMD to be added to the current build, the WDB visionTMD connection entry must be made the active WDB connection. By default, when this project was built, the WDB END driver connection was included in the project. That entry now appears bolded because it is the active connection.
In order for the project to build correctly, only one WDB connection can be active. To include the WDB visionTMD connection, right-click on Select WDB connection and select Configure `select WDB connection' on the pop-up menu. The properties dialog wind appears.
Click on the Components tab, scroll down the list, and click on the WDB visionTMD connection check box. The WDB END driver connection will automatically be deselected. Click the Apply button to select the TMD component. If the Include Component(s) dialog contains the correct information, click Ok to confirm it and close the dialog box. The WDB visionTMD connection is now the active connection.
The debugger being used must be configured correctly to download the vxWorks image created in the previous steps to the target. The debugger will also be used to start the image running once it has been downloaded. Once the image is running on the target, the TM Driver will also be available since the WDB agent that is included in the vxWorks image uses the TM Driver as the connection mechanism.
Instructions for configuring the debugger and downloading and executing the vxWorks image on the target are provided for two of Wind Rivers debuggers in the Transparent Mode Driver User's Guide.
|
|
|||||||||||||||||||
Information on configuring visionICE II for network operation is available in the visionICE II User's Manual. In addition, the UDP Console Port must be set to 17185.
Once the VxWorks image is running on the target, the host will be able to communicate with the running WDB agent. To do this, a target server must be configured and activated. Follow the following steps:
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
To launch a correctly configured target server using the command line, enter the following:
% tgtsvr.exe -n 127.0.0.1 -V -B wdbrpc -R C:/Tornado/2.2 -RW -c myCoreFile
For more information about using either the GUI or the command line to configure target servers, see 2.7 Starting a Target Server.
Once you have configured your host software and target hardware, you are ready to start a terminal emulator and boot VxWorks.
Select either VxWorks COM1 or VxWorks COM2 from the same program folder as other Tornado programs, according to whether the serial connection from your target is to COM1 or COM2 of your host PC. (See Connecting a Serial Cable for the Terminal Emulator.)
|
|
WARNING:
If you are using a VxWorks image configured for a network connection (the default), you must have an FTP server running on the host where the VxWorks system image is stored. See Initializing the Host Network Software for more information.
|
||||||||||||||||||
When you boot VxWorks with the default boot program (from ROM, diskette, or other medium), you must use the VxWorks command line to provide the boot program with information that allows it to find the VxWorks image on the host and load it onto the target. The default boot program is designed for a networked target, and needs to have the correct host and target network addresses, the full path and name of the file to be booted, the user name, and so on.
Unless your target CPU has nonvolatile RAM (NVRAM), you will eventually find it useful to build a new version of the boot loader that includes all parameters required for booting a VxWorks image (see 4.8 Configuring and Building a VxWorks Boot Program). In the course of your developing an application, you will also build bootable applications (see 4.5 Creating a Bootable Application).
When you power on the target hardware (and each time you reset it), the target system executes the boot program from ROM; during the boot process, the target uses its serial port to communicate with your terminal or workstation. The boot program first displays a banner page, and then starts a seven-second countdown, visible on the screen as shown in Figure 2-7. Unless you press any key on the keyboard within that seven-second period, the boot loader will attempt to proceed with a default configuration, and will not be able to boot the target with VxWorks.
The boot program displays the VxWorks boot prompt, as follows:
[VxWorks Boot]:
To display the current (default) boot parameters, type p at the boot prompt, as follows:
[VxWorks Boot]: p
A display similar to the following appears; the meaning of each of these parameters is described in the next section. This example corresponds to the configuration shown in Figure 2-8. (The p command does not actually display the lines with blank fields, although this example shows them for completeness.)
boot device : ln processor number : 0 host name : mars file name : c:\tornado\target\config\bspname\vxWorks inet on ethernet (e) : 90.0.0.50:ffffff00 inet on backplane (b) : host inet (h) : 90.0.0.1 gateway inet (g) : user (u) : fred ftp password (pw)(blank=use rsh) :secret flags (f) : 0x0 target name (tn) : phobos startup script (s) : other (o) :
To change the boot parameters, type c at the boot prompt, as follows:
[VxWorks Boot]: c
In response, the boot program prompts you for each parameter. If a particular field has the correct value already, press ENTER. To clear a field, enter a period ( . ), then press ENTER. If you want to quit before completing all the parameters, type CTRL+D.
Network information must be entered to match your particular system configuration. The Internet addresses must match those in your system's hosts file (or those known to your Domain Name Server), as described in Establishing the VxWorks Target Name and IP Address.
If your target has nonvolatile RAM (NVRAM), the boot parameters are stored there and retained even if power is turned off. For each subsequent power-on or system reset, the boot program uses these stored parameters for the automatic boot configuration.
The VxWorks boot program provides a limited set of commands. To see a list of available commands, type either h or ? at the boot prompt, followed by ENTER:
[VxWorks Boot]: ?
Table 2-3 describes each of the VxWorks boot commands and their arguments.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Each of the boot parameters is described below, with reference to the example in 2.5.2 Entering New Boot Parameters. The letters in parentheses after some parameters indicate how to specify the parameters in the command-line boot procedure described in 2.5.6 Alternate Boot Methods.
Figure 2-9 shows a typical VxWorks boot display. The VxWorks boot program prints the boot parameters, and the downloading process begins. The following information is displayed during the boot process:
$ln(0,0)mars:c:\tornado\target\config\bsp\vxWorks e=90.0.0.50 h=90.0.0.1 u=fred pw=
The order of the assigned fields (those containing equal signs) is not important. Omit any assigned fields that are irrelevant. The codes for the assigned fields correspond to the letter codes shown in parentheses by the p command. For a full description of the format, see the reference entry for bootStringToStruct( ) in bootLib.
This method can be useful if your workstation has programmable function keys. You can program a function key with a command line appropriate to your configuration.
As noted previously, if your target CPU has nonvolatile RAM (NVRAM), all the values you enter in the boot parameters are retained in the NVRAM. In this case, you can let the boot program auto-boot without having a terminal connected to the target system.
See 4.8 Configuring and Building a VxWorks Boot Program for instructions on creating a new boot program for your boot media, with parameters customized for your site. With this method, you no longer need to alter boot parameters before booting.
You can boot a target that is not on a network most easily over a serial line with the Target Server File System (TSFS). The TSFS provides the target with direct access to the host's file system. Using TSFS is simpler than configuring and using PPP or SLIP.
To boot a target using TSFS, you must first reconfigure and rebuild the boot program, and copy it to the boot medium for your target (for example, burn a new boot ROM or copy it to a diskette). See 4.8 Configuring and Building a VxWorks Boot Program.
Before you boot the target, configure a target server with the TSFS option and start it. See Target Server File System.
The only boot parameters required to boot the target are boot device and file name (see 2.5.4 Description of Boot Parameters). The boot device parameter should be set to tsfs. The file name parameter should be set relative to the TSFS root directory that is defined when you configure the target server for the TSFS. You can configure the boot program with these parameters, or enter them at the VxWorks prompt at boot time.
When VxWorks is running, there are several ways you can reboot VxWorks. Rebooting by any of these means restarts the attached target server on the host as well:
To start Tornado, click on the Start button on the Windows taskbar and select Programs. Then select the Tornado program group (called Tornado with default installation), and click on Tornado.
When you first start Tornado, the project facility Create Project window is displayed (Figure 2-10).
The top of the main window contains five toolbars; the toolbars provide quick access to the most frequently used Tornado commands. Figure 2-11 shows the default toolbar configuration.
You can dock any toolbar at the top, side, or bottom edge of the Tornado window. You can also drag any toolbar away from the edges of the window to make it a a floating palette, which you can place anywhere on the screen. To move a toolbar, position the mouse pointer between any of its buttons (or on the title bar of a floating toolbar), and then drag the toolbar to the position you prefer.
For a concise description of the purpose of any toolbar button, hold the mouse pointer over it for a short interval to display a tooltip window with the name of the button.
The Tornado Launch toolbar has a pull-down list box that shows all the target servers that are currently running and known to the Tornado registry that your system is using (shown in Figure 2-12 as a floating palette). If no target servers are listed, or none of the ones listed represent the target you need, you must configure and start a target server.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
Starts a browser for the selected target. 9. Browser describes how to use the browser.
|
|||||||||||||||||||
|
Starts a Tornado shell for the selected target. 7. Shell describes how to use the shell.
|
|||||||||||||||||||
|
Starts the debugger. 10. Debugger describes how to use the debugger.
|
|||||||||||||||||||
|
Starts the VxWorks target simulator. 6. VxSim describes the simulator. The Tornado Getting Started Guide and 4. Projects include information about using the simulator.
|
|||||||||||||||||||
|
|
|||||||||||||||||||
When you first start Tornado, most of the buttons in toolbars are disabled. Tornado enables and disables buttons and menu commands so that only the commands that are currently meaningful are enabled. For example, at first the only buttons enabled are those for creating or opening a file, and displaying Tornado help. Once a file is open, more buttons become enabled; when you make a selection, the buttons that act on that selection become active, and so on.
The fields at the bottom right of the status line (at the bottom of the main Tornado window) provide information about the current state of keyboard toggles. These fields display the following indicators:
Once a Tornado session is in progress, you are likely to have many specialized windows open or iconized within Tornado: one or more editor windows, browser windows inspecting assorted system objects, disassembly windows, build output windows, and so on. To manage these sub-windows, use the commands in the Window menu.
The top pane of the Window menu contains commands to rearrange or dismiss all open sub-windows:
The remainder of the Window menu selects particular sub-windows. Build Output is always present, and opens a window that displays the output of the most recent build command from the Project menu.
At the bottom of the Window menu is a list of all currently available windows. Click on any item in the list to display its window.
A target server manages communications between Tornado host tools and the VxWorks target agent (or an alternate agent) on the target system. A target server must be configured for the target, and started, before the host tools can interact with the target.
The target server must be configured with the same communication back end as the one built into the VxWorks image. Communication back ends include drivers for specific modes of communication between the host and target, such a network (IP), serial line, and so on.
The default communication back end for the VxWorks images shipped with Tornado is for a network connection. Configuring a target server for the default connection and image simply involves identifying the IP address of the target. It is also useful to provide an alternative to the default target server name.
To configure a target server, select Tools>Target Server>Configure. Tornado opens the Configure Target Servers dialog box (Figure 2-13).
|
CAUTION:
If you are going to use a host-target connection other than the default one for a network connection, see 8.2 Configuring and Starting a Target Server and 4.7 Configuring the Target-Host Communication Interface.
|
||||||||||||||||||
You can check whether everything is working properly by select your target server from the drop-down list box in the Tornado Launch toolbar, and clicking the
button next to it. A Browser window similar to the one shown in Figure 2-14 should appear, displaying summary information about the target.
If you encountered problems booting or exercising VxWorks, there are many possible causes. This section discusses the most common sources of error and how to narrow the possibilities. Please read 2.9.1 Things to Check before contacting Wind River customer support. Often, you can locate the problem just by re-checking the installation steps, your hardware configuration, and so forth.
|
|
|||||||||||||||||||
For targets on a VMEbus backplane, most configurations require that the P2 B row is bussed and that there is power supplied to both the P1 and P2 connectors.
The only exception to this is if the backplane is jumpered to propagate the BUS GRANT and INT ACK daisy chains.
In most cases, the documentation accompanying your hardware describes its cabling requirements. One common problem: make sure your serial cable is a null-modem cable, if that is what your target requires.
For example, connect a known working system to the transceiver and check whether the network functions.
An Internet address consists of a network number and a host number. There are several different classes of Internet addresses that assign different parts of the 32-bit Internet address to these two parts, but in all cases the network number is given in the most significant bits and the host number is given in the least significant bits. The simple configuration described in this chapter assumes that the host and target are on the same network--they have the same network number. (See VxWorks Network Programmer's Guide: TCP/IP under VxWorks for a discussion of setting up gateways if the host and target are not on the same network.) If the target Internet address is not on the same network as the host, the VxWorks boot program displays the following message:
Error loading file: errno = 0x33.
0x33 corresponds to errno 51 (decimal) ENETUNREACH. (This is one of the POSIX error codes, defined for VxWorks in c:\tornado\target\h\errno.h.)
If the target Internet address is not in the appropriate hosts file (or the DNS equivalent), then the host does not know about your target. The VxWorks boot program receives an error message from the host:
host name for your address unknown Error loading file: status = 0x320001.
0x32 is the VxWorks module number for hostLib 50 (decimal). The digit "1" corresponds to S_hostLib_UNKNOWN_HOST. See the errnoLib reference entry for a discussion of VxWorks error status values.
Is the FTP server configured correctly? See F. FTP Server for more information on configuring the FTP Server if you are using wftpd32.exe (shipped by Wind River). Otherwise, consult your system documentation on the FTP Server shipped with it.
C:\> ping venus Pinging venus.wrs.com [91.0.10.1] with 32 bytes data:
Reply from 91.0.10.1: bytes=32 time=10ms TTL=255 Reply from 91.0.10.1: bytes=32 time<10ms TTL=255 Reply from 91.0.10.1: bytes=32 time<10ms TTL=255 Reply from 91.0.10.1: bytes=32 time<10ms TTL=255
C:\> arp -a Interface: 91.0.10.26 Internet Address Physical Address Type 91.0.10.1 08-00-20-1b-66-e9 dynamic 91.0.10.20 00-20-af-52-1e-72 dynamic 91.0.10.254 00-00-ef-01-f1-a0 dynamic
C:\> netstat -r
Route Table
Network Address Netmask Gateway Address Interface Metric
0.0.0.0 0.0.0.0 91.0.10.254 91.0.10.26 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
91.0.10.0 255.255.255.0 91.0.10.26 91.0.10.26 1
91.0.10.26 255.255.255.255 127.0.0.1 127.0.0.1 1
91.11.255.255 255.255.255.255 91.0.10.26 91.0.10.26 1
224.0.0.0 224.0.0.0 91.0.10.26 91.0.10.26 1
255.255.255.255 255.255.255.255 91.0.10.26 91.0.10.26 1
Active Connections
Proto Local Address Foreign Address State TCP mercury:1025 saturn.wrs.com:nbsession ESTABLISHED TCP mercury:1177 earth.wrs.com:nntp ESTABLISHED TCP mercury:1259 oak.oakland.edu:ftp ESTABLISHED
If you use a WDB Serial connection to the target, make sure you have connected the serial cable to a port on the target system that matches your target-agent configuration. The agent uses serial channel 1 by default, which is different from the channel used by VxWorks as a default console (channel 0). Your board's ports may be numbered starting at one; in that situation, VxWorks channel one corresponds to the port labeled "serial 2."
The target server requires a host-resident image of the VxWorks run-time system. By default, it obtains a path for this image from the target agent (as recorded in the target boot parameters). In some cases (for example, if the target boots from a local device), this default is not useful. In that situation, use the Core file field in the Create Target Server form (see Core File and Symbols) or the equivalent -c option to tgtsvr (in the online Tornado API Reference under Tornado Tools) to specify the path to a host-resident copy of the VxWorks image.
If you have questions or problems with Tornado or with VxWorks after completing the above troubleshooting section, or if you think you have found an error in the software, contact the Wind River customer support organization. Your comments and suggestions are welcome as well. For information about customer support, see 1.6 Customer Services.
1:
The Tornado registry program is the file c:\tornado\host\x86-win32\bin\wtxregd.exe.
The Windows NT service version is wtxregds.exe.
2: NetROM is a trademark of Applied Microsystems Corporation.
3: If the same pathname is not suitable for both host and target--for example, if you boot from a disk attached only to the target--you can specify the host path separately to the target server, using the Core file field (-c option). See 8.6 Managing a Target Server.