![[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).
