Each of the boot parameters is described below, with reference to the example shown above.
The letters in parentheses after some of the parameters are alternative names used with the single-string interactive configuration method described in 3.5.3 Changing Boot Parameters Interactively, p.42, and the static configuration method described in 3.7.3 Configuring Boot Parameters Statically, p.45.
For information about booting an image stored on a local target file system, see 3.10 Booting From a Target File System, p.53.
boot device
The type of device from which to boot VxWorks. This must be one of the drivers included in the boot loader (for example, enp for a CMC controller). Due to limited space in boot media, only a few drivers can be included. A list of the drivers included in the boot loader image can be displayed in the boot loader shell with the devs or h command. For more information about boot devices, see
3.7.5 Selecting a Boot Device, p.46.
unit number
The unit number of the boot device, starting at zero.
processor number
For systems with multiple targets on a backplane, the processor number must be set—and unique—for each target. The backplane master must have the processor number set to zero.
For multicore systems, the processor number must be set—and unique—for each CPU. Otherwise, a value of zero is commonly used, but is not required.
host name
The name that the target uses for the host machine. It does not need to be the name used by the host itself. The default value for host name is simply host. To avoid any confusion, change it to something more meaningful for your environment. In the example in 3.5.1 Displaying Current Boot Parameters, p.38, the host name is mars.
The host name parameter is not used for a network boot process (using TFTP, FTP, or RSH). Its primary use is for accessing remote file systems over non-NFS network connections from the target after VxWorks has booted. For information in this regard, see 11.5 Remote File System Access From VxWorks, p.263.
Once VxWorks has booted, the host name can be displayed in the device list that is produced by the devs command from a VxWorks shell.
file name
The full path name of the VxWorks image to be booted (c:\myProj\vxWorks in the example). This path name is also reported to the host when you start a target
inet on ethernet (e)
The Internet Protocol (IP) address of a target system Ethernet interface, as well as the subnet mask used for that interface. The address consists of the IP address, in dot decimal format, followed by a colon, followed by the mask in hex format (here, 90.0.0.50:ffffff00).
inet on backplane (b)
The Internet address of a target system with a backplane interface (blank in the example in 3.5.1 Displaying Current Boot Parameters, p.38).
host inet (h)
The Internet address of the host that provides the VxWorks image file (90.0.0.1 in the example in 3.5.1 Displaying Current Boot Parameters, p.38).
gateway inet (g)
The Internet address of a gateway node for the target if the host is not on the same network as the target (blank in the example in 3.5.1 Displaying Current Boot Parameters, p.38).
user (u)
The user ID used to access the host for the purpose of loading the VxWorks image file (which is fred in the example). The user must have host permission to read the VxWorks image file.
On a Windows host, the user specified with this parameter must have FTP access to the host, and the ftp password parameter (below) must be used to provide the associated password.
On a UNIX (Linux or Solaris) host, the user must have FTP, TFTP, or rsh access.
For rsh, the user must be granted access by adding the user ID to the host's /etc/host.equiv file, or more typically to the user's .rhosts file (~userName/.rhosts).
ftp password (pw)
For FTP or TFTP access, this field is used for the password for the user identified with the user parameter (above). For RSH access it should be left blank.
flags (f)
The flags configuration options are described in Table 3-9. The options are specified as a value that is the sum of the values of selected option bits. (The example in 3.5.1 Displaying Current Boot Parameters, p.38 shows the flags parameter as zero (0x0), which indicates that no option bits were set.)
! CAUTION: For the files of a remote host to be accessible with RSH or FTP, permissions and user identification must be established on both the remote and local systems. See user (u), p.40 and ftp password (pw), p.40.
NOTE: If this parameter is not used, the boot loader attempts to load the run-time system image using a protocol based on the UNIX RSH utility, which is not available for Windows hosts.
3 Boot Loader 3.5 Boot Parameters
Loading All Symbols
The 0x02 option bit (SYSFLG_DEBUG) is used to load local symbols as well as globals. Note that loading a very large group of symbols can cause delays of up to several minutes while Workbench loads the symbols. For information about how to specify the size of the symbol batch to load, see the Wind River Workbench by Example guide. Also note that the 0x02 option bit can only be used with the downloadable symbol table; it cannot be used with the standalone symbol table.
For information about symbol tables,and about use of symbol tables when calling routines from kernel shell, see the VxWorks Kernel Shell User’s Guide.
Using DHCP
The 0x40 option bit (SYSFLG_AUTOCONFIG) can be used with the flags parameter
Table 3-9 Values for flags Parameter
Macro Option Bit Description
SYSFLG_NO_SYS_CONTROLLER 0x01 Do not enable the system controller, even if the processor number is 0. This option is board specific; refer to your target documentation.
SYSFLG_DEBUG 0x02 Load local symbols as well as globals (see Loading All Symbols, p.41).
SYSFLG_NO_AUTOBOOT 0x04 Do not auto-boot.
SYSFLG_QUICK_AUTOBOOT 0x08 Auto-boot fast (short countdown).
SYSFLG_NO_SECURITY 0x20 Disable login security.
SYSFLG_AUTOCONFIG 0x40 Use DHCP to obtain target IP and gateway boot parameters (see Using DHCP, p.41).
SYSFLG_TFTP 0x80 Use TFTP to get boot image.
SYSFLG_SYS_MODE_DEBUG 0x400 Set the system debug flag to enable the WDB target agent and to specify debug mode for fatal error handling. For more information, see E.4 Enabling the WDB Target Agent, p.706 and 18.6 Setting Fatal Error Handling Mode, p.449.
SYSFLG_AUTOFILE 0x800 Use DHCP to obtain boot file name and host IP address (see Using DHCP, p.41).
The 0x800 option bit (SYSFLG_AUTOFILE) can be used with the flags parameter so that the following boot parameters are set by the DHCP server:
■ file name—the name of the image file to be booted (see file name, p.39)
■ host inet—the IP address of the host that provides the VxWorks image file (see host inet (h), p.40)
For information about DHCP, see the Wind River Network Stack Programmer’s Guide.
target name (tn)
The name of the target system to be added to the host table (in the example in 3.5.1 Displaying Current Boot Parameters, p.38, it is phobos).
startup script (s)
If the kernel shell is included in the downloaded image, this parameter allows you to pass to it the path and filename of a startup script to execute after the system boots. A startup script file can contain only the shell’s C interpreter commands.
(Do not add the INCLUDE_SHELL, INCLUDE_SIMPLE_BANNER, or
INCLUDE_WDB_BANNER, component to a boot loader. These components conflict with the boot loader shell. Doing so causes project configuration errors.)
This parameter can also be used to specify process-based (RTP) applications to run automatically at boot time, if VxWorks has been configured with the appropriate components. See VxWorks Application Programmer’s Guide.
other (o)
This parameter is generally unused and available for applications (blank in the example in 3.5.1 Displaying Current Boot Parameters, p.38). It can be used, for example, for specifying the default network interface when booting from a file system device. For more information, see 3.7.4 Enabling Networking for Non-Boot Interfaces, p.46.