To set boot parameter values, you can enter the parameter values manually at boot time, or you can set various #defines to create a default boot line. You also have the option of using either a DHCP or BOOTP client to retrieve certain parameters (such as IP address, boot file name, and so on) from a remote server.

The default boot line is specified during configuration. The relevant configuration macro is DEFAULT_BOOT_LINE. A valid setting looks like:

"ei(0,0)host:/vw/config/mv166/vxWorks h=90.0.0.3 e=90.0.0.50 u=target"

When control passes to the run-time VxWorks image, VxWorks parses the boot line at the known memory location and loads the values into a BOOT_PARAMS structure and checks for missing boot parameters. At this point, if you booted using TFTP, the only parameters that could be missing are: hostName, targetName, usr, passwd, startupScript, and other. Otherwise, the boot would have failed.¹

However, these parameters can be useful to the run-time image even if they were not essential to the boot program. Therefore, it is possible to include values for these parameters in the run-time VxWorks image. To do this, reconfigure VxWorks. For more information on configuring VxWorks, see the Tornado User's Guide: Projects. The relevant configuration macros are the following:

HOST_NAME_DEFAULT

Supplies a hostName value, the name of the system that supplied the boot file, bootFile. This name is added to the target's host table to provide a convenient label for the host machine at the IP address, had. The hostName is added to the host and route tables. At startup, the run-time VxWorks image creates a netDrv device named "hostName:".

TARGET_NAME_DEFAULT

Supplies a targetName value, the name of the target. This name is added to the target's host table to provide a convenient label for the target's IP address, had.

HOST_USER_DEFAULT

Supplies a usr value, the login name that this target's netDrv device should use.

HOST_PASSWORD_DEFAULT

Supplies a passwd value, the password (if any), to use. If there is a non-empty passwd, this has configuration consequences for netDrv as well as for remote login from the VxWorks target to a remote system. A password here tells netDrv device, "hostName:",² to use FTP for remote file access. Otherwise, it uses RSH.

SCRIPT_DEFAULT

Supplies a value for startupScript, the startup script for the VxWorks target-based shell (if any). You can use this script to do things such as redirect output.

OTHER_DEFAULT

Supplies an other value. If the booted VxWorks image must access a local SCSI disk, you can use the other parameter to specify which network interface to attach.

If you supply a boot line manually, its values take precedence over parameters specified by any other source (except those few parameters retrieved by DHCP or BOOTP). To check the values of all currently set boot parameters, type p at the VxWorks prompt. This command lists all currently set boot parameters and their values. For example:

[VxWorks Boot]: p 
boot device           : ln 
processor number      : 0 
flags (f)             : 0xc0 
unit number           : 0

Before you can boot the target from the network, you must enter appropriate values for bootDev (boot device), procNum (processor number), flags, and unitNum (unit number). The target can store these values in NVRAM (if available) and use them in subsequent boot sessions.

To change the boot device, processor number, flags value, or unit number, enter a c at the boot prompt. This runs a script that prompts you for individual boot parameters. To bypass the script and enter the whole boot line all at once, enter a $ followed by the boot line.

If you intend to use a DHCP or BOOTP message to supply additional parameters, make sure that you specify a flags value that sets the 0x40 bit (the dynamic configuration bit). Although this setting is the same for both DHCP and BOOTP, the VxWorks startup code automatically uses DHCP if available. If DHCP is unavailable, the startup code uses BOOTP. Typically, the boot image contains either a DHCP or BOOTP client and not both. However, if, for some reason, you have included both clients in the boot image, the BOOTP client is ignored and the boot image is larger than it need be.

To make a DHCP or BOOTP client available at boot time, you must construct boot ROMs that contain the client code.

If the boot program includes a DHCP or BOOTP client, and you have set the 0x40 bit in the flags boot parameter, the boot program uses the DHCP or BOOTP client to retrieve values for ( )(from which the boot program derives bad), had, gad, and bootFile.

	NOTE: This section provides a general discussion of the issues that arise when using a DHCP or BOOTP server to provide boot parameters. For more on configuring the DHCP or BOOTP servers, see Configuring VxWorks to Include the DHCP Components, or BOOTP Configuration.

IP Lease Length

When booting with DHCP, the value of the minimum lease length is critical. Because the network address assigned by DHCP is only valid for a finite period of time, the DHCP client must spawn a monitor task to renew the lease as necessary. However, this cannot occur until after the VxWorks boot file has been downloaded.

Thus, the minimum lease setting must be large enough to allow this download to complete. Otherwise, the server which supplied the IP address may reassign it after the lease expires, and the VxWorks image will inadvertently use an invalid IP address. The default value is acceptable for an Ethernet link, but might need to be increased for slower connections, such as serial links.

Booting a VxWorks Target with DHCP from a Windows NT Server

The Windows NT implementation of the DHCP server is geared towards providing configuration parameters for other Windows NT workstations. As a result, it does not provide all the information necessary to boot a VxWorks target successfully.

In particular, the Windows NT implementation of the DHCP server does not provide a boot file name. Thus, to use DHCP to boot a VxWorks target from a Windows NT Server, you must enter the boot file name manually at the boot prompt. In addition, the Windows NT implementation of DHCP server does not provide for the case in which the DHCP server that provides the configuration parameters is resident on one machine while the boot file is resident on another. Thus, you have to enter the host IP address manually.

Normally, the Tornado target server retrieves the run-time VxWorks image from the target. Unfortunately, because the NT DHCP server does not provide the target with the name of this file, the target cannot provide the file name to the target server. To get around this lack in the NT implementation of DHPC, you must supply Tornado with the name of the VxWorks run-time image. To do this, go the Create Target Server window (accessible from the Tornado Launcher window by selecting Target: Create), then use the Core field to specify a VxWorks image file. This file need not be the actual image used by the target. It can be a locally accessible copy of that image.

Getting the Target Ethernet Address

When you configure the BOOTP server, you need the target's hardware address to use as a key into the BOOTP database. You get this address from the target device. If the device is running VxWorks, you can use the ifShow( ) command. In the following example, the target's Ethernet address is 00:00:4b:0b:b3:a8.³

-> ifShow "ln0" 
value = 0 = 0x0

The output is sent to the standard output device, and looks like the following:

ln (unit number 0): 
Flags: (0x63) UP BROADCAST ARP RUNNING  
Internet address: 150.12.1.240 
Broadcast address: 150.12.1.255 
Netmask 0xffff0000 Subnetmask 0xffffff00 
Ethernet address is 00:00:4b:0b:b3:a8 
Metric is 0 
Maximum Transfer Unit size is 1500 
5 packets received; 6 packets sent 
0 input errors; 0 output errors 
6 collisions 

If the device has not yet booted, you can use the n command to retrieve the information from the boot ROMs. For example:

[VxWorks Boot]: n ln 
Attaching network interface enp0... done 
Address for device "ln" == 02:cf:1f:e0:20:24

1:  If you booted using RSH, you had to have provided the boot program with a value for usr. If you booted using FTP, you had to have provided values for usr and passwd.

2:  The presence or lack of a passwd affects only the "hostName:" device. Other instances of netDrv are individually configurable.

3:  The ifShow( ) function is not built in to the Tornado shell but must be activated by turning on network debugging. The relevant configuration macro is INCLUDE_TCP_SHOW.