2. BASIC HOST AND TARGET SETUP (basicNetConfiguration.txt)
   -------------------------------------------------------

   2.1 Introduction
   2.2 Booting Process Overview 
   2.3 Boot Parameters Description
   2.4 Target Shell Transcript
   2.5 Network Driver Selection and Configuration
   2.6 Serial Console Setup
   2.7 Target Server and WDB Agent Setup
   2.8 Build Methods
       2.8.1 Building Bootrom Images
       2.8.2 Building Runtime Images
       2.8.3 Tornado 101 Build Method
       2.8.4 Project Facility Build Method

APPENDICES

APPENDIX A. TORNADO 101 BUILD METHOD DIRECTIONS
APPENDIX B. PROJECT FACILITY BUILD METHOD DIRECTIONS
APPENDIX C. CONFIGURING ADDITIONAL NETWORK INTERFACE DRIVERS
APPENDIX D. DHCP CLIENT CONFIGURATION


                 2.  BASIC HOST AND NETWORK SETUP
                 --------------------------------

2.1 INTRODUCTION
----------------
 
The most common method of communication with a vxWorks target
works as follows:

Target boots running the bootrom image whose job it is to
download a vxWorks runtime image over the network, serial
connection, or local device.  Target's serial port (COM 1) is
connected to host's serial port (COM 1 or COM 2).  Boot
parameters are entered/changed in hyperterminal program running
on the host.    When the runtime image is loaded successfully,
the WDB agent task waits to get commands from a target server.
Target server running on the host attaches to the target
(commonly serial or network connection).  A tool like the
host-based shell, WindSh, running on the host gets commands
from the user and talks to the target server.  The target server
sends the command to the WDB agent, gets the response, and
turns it over to the tool.  At this point, the answer is
displayed on WindSh.

If the target server cannot connect to the WDB agent (rpccore
backend client RPC: Timed out, reported in the target server
window), then the WindSh will be useless.   It is convenient
then, to build a kernel with network show libraries and a
target-based shell that communicates with the host over the
serial port, which can be used to troubleshoot network problems.

Booting a target requires the following steps:

   a. Select and configure a supported network interface card.
      Using the default network interface card for the BSP is
      the easiest choice.

   b. Select protocol to download the runtime image.  Set up
      server at the host.  Change the boot parameters
      accordingly.  FTP is easiest.

   c. Consult your system administrator to get a unique IP
      address for the target.  You will also need to obtain
      the proper subnet mask.   Getting a static IP address
      rather than using DHCP or BOOTP is easiest.
   
   d. Choose how the target server and the WDB agent will
      communicate.  Network communication is fastest.  Set up
      the target server and the WDB agent parameters
      accordingly.

   e. Set up the host's hyperterminal and adjust serial console
      configuration parameters accordingly.

   f. Choose a build method to configure runtime image:
      T101 or Project Facility.

   g. Build a bootrom image using the T101 build method, if
      necessary.

   h. Build runtime image with support for target shell and
      network show libraries.

Once the target boots, basic connectivity can be verified from
the target shell.  If the target can ping the host, a target
server can be connected, and host tools like WindSh can be used.

Details are discussed in the following sections:

   2.2 BOOTING PROCESS OVERVIEW

       Interaction between bootrom and runtime images.
 
   2.3 BOOT PARAMETERS DESCRIPTION

       Meaning of boot parameters and how vxWorks uses the
       information provided, or reacts to missing parameters,
       when it initializes the network modules.
   
   2.4 TARGET SHELL TRANSCRIPT

       Transcript shows a target booting successfully, and some
       of the debugging information available from the shell.

   2.5 NETWORK DRIVER SELECTION AND CONFIGURATION

       Outlines how to select and configure END and BSD44
       drivers.

   2.6 SERIAL CONSOLE SETUP
  
       Configuration steps needed to set up the target's serial
       console whose output goes to the hyperterminal on the
       host. It is convenient to do this, even with PC targets,
       since the hyperterminal has a capture buffer where debug
       messages can be read later and also to cut and paste
       information forwarded to Customer Support.

   2.7 TARGET SERVER AND WDB AGENT SETUP

       Explains the different communication modes the WDB agent
       and the target server can use.  It also discusses
       conflicts with other libraries, and how the target
       server's communication mode must match the WDB agent
       configuration.

   2.8 BUILD METHODS OVERVIEW
 
       Available build methods in Tornado 2.0: The Tornado 101
       Method and the Project Facility GUI.

 
2.2 BOOTING PROCESS OVERVIEW
----------------------------

The bootrom image is a minimal vxWorks kernel with full network
support that can use a variety of network protocols to download
the boot file (FTP, TFTP, and RSH) and to get an IP address
(BOOTP or DHCP), if necessary.  The bootrom leaves the boot
parameters in a place where the vxWorks runtime image can
access them later as it initializes its network module.

The bootrom image finds the boot parameters in NVRAM or the
compiled DEFAULT_BOOT_LINE for those targets without NVRAM
(i.e. PC targets).  The bootrom image will set up whatever is
necessary to obtain the boot file based on the modules that
were defined when the bootrom image was compiled.

If the boot device is a network driver, the boot device name
is searched in the list of defined network drivers.   If a
match is found, the interface is configured with the provided
IP address.  The appropriate server on the host (FTP, TFTP, or
RSH) is contacted to get the boot file.  If the boot file is
obtained successfully, the bootrom code jumps into the starting
code of the runtime image.

The runtime image will initialize the network libraries and
network drivers based on the boot line parameters left by the
bootrom image and the defined network libraries when the
runtime image was compiled.  The route table, host table,
remote access devices, and present working directory will be
configured based on the boot parameters.


2.3 BOOT PARAMETERS DESCRIPTION
-------------------------------

This section explains the meaning of boot parameters and how
vxWorks uses the information provided, or reacts to missing
parameters, when it initializes the network modules.

Boot parameters can be changed at the boot prompt.  Targets
without NVRAM (i.e. PC targets) get boot parameters from
the DEFAULT_BOOT_LINE from:

   Tornado/target/config/BSP directory/config.h
 
DEFAULT BOOT LINE PARAMETERS examples:

   1. Boot device is a network interface card (elPci):

   #define DEFAULT_BOOT_LINE \
        "elPci(0,0)zlot:/projpentium/default/vxWorks \
         h=147.11.41.98  e=147.11.41.180:ffffff00 \
         u=mypctarget \
         s=/projpentium/script.txt  pw=myPassword"

   which will be displayed as:

   boot device          : elPci
   unit number          : 0
   processor number     : 0
   host name            : zlot
   file name            : /projpentium/default/vxWorks
   inet on Ethernet (e) : 147.11.41.180:ffffff00
   host inet (h)        : 147.11.41.98
   user (u)             : mypctarget
   ftp password (pw)    : myPassword
   flags (f)            : 0x0
   startup script (s)   : /projpentium/script.txt


   2. Boot device is local device (floppy drive).  Notice the
      use of the "o" parameter.

   #define DEFAULT_BOOT_LINE \
      "fd=0,0(0,0)zlot:/projpentium/default/vxWorks \
       h=147.11.41.98  e=147.11.41.180:ffffff00 u=mypctarget \
       s=/projpentium/script.txt  pw=myPassword o=elPci"

   3.  Host and target are not on the same subnet.  Gateway is
       needed:

   #define DEFAULT_BOOT_LINE \
      "elPci(0,0)zlot:/projpentium/default/vxWorks \
       h=147.11.48.28  e=147.11.41.180:ffffff00 \
       g= 147.11.41.254 u=mypctarget \
       s=/projpentium/script.txt  pw=myPassword \
       tn=PCtarget"

BOOT PARAMETERS 

   OTHER (Ex: o=elPci)
   -------------------
   If boot device is a local device (fd, ata, tffs...) it is necessary
   to define the "other" parameter to specify the network card to be
   initialized.  If using the T2 Project Facility build method, a
   check for tffs as a local device is missing from
   target/config/comps/src/net/usrNetBoot.c.  This is SPR# 28561.
   In usrNetDevNameGet function, add:

      (strncmp (sysBootParams.bootDev, "tffs", 2) == 0)) ||

   to take care of the problem.


   HOST NAME (Ex = zlot)
   ---------------------

   Arbitrary name for the computer that supplies the boot file. "host"
   is the default name.


   HOST IP ADDRESS (Ex: h=147.11.41.98)
   ------------------------------------

   IP address of the host zlot.


   INET ON ETHERNET (Ex: e=147.11.41.180:ffffff0)
   ----------------------------------------------

   Target's IP address and subnet mask.

   IP address must be unique.  Consult your system administrator
   to get a unique IP address and to determine the appropriate
   subnet mask.  If mask is not given, the standard mask for
   the address class will be used.

   If the mask is incorrect, the ARP table in the target can
   become very large and can result in
   "arpresolve: can't allocate llinfo" error messages.
   If you want to change the mask later, call the following
   functions in the following order.  Order is important.  Failure to
   call the 3 functions in that order will result in a misconfigured
   route table.

   Example:

   ifRouteDelete ("dc",0): to delete the existing network route for
                           the device "dc", unit 0.
   ifMaskSet("dc0", 0xffffff00): to enter a mask.
   ifAddrSet("dc0", "147.11.41.180"): to set the IP address.


   GATEWAY
   -------

   This parameter is needed if target and host are not on the
   same subnet.   Do not use this field to enter the default
   gateway (the router's address) if the host and the target
   are in the same subnet.  The route will not be added.
   Enter the default route using routeAdd("0", "10.1.2.1"),
   for example, in your application startup code or startup
   script.

   USER NAME (Ex: u=mypctarget)
   ----------------------------

   User name that rsh and ftp will use to access the host.  mypctarget
   must have been added in .rhosts or be a login name in UNIX systems.
   In Windows, mypctarget must be added as a user name for the FTP
   server.  mypctarget will be added to the target's host table.

   PASSWORD (Ex: pw=myPassword)

   Password given to the FTP server running on the host.  vxWorks will
   access the host's directories through FTP if pw is defined. If pw
   is not defined, access will be through rsh, which is normally
   available in UNIX systems only.  On the host side, make sure FTP is
   up and running. Verify that the FTP user name and password match the
   boot parameters user name and password.  A device will be created
   in the target to access the hosts' files remotely which will be
   listed under ->devs.  Most hosts have an FTP server.  If your host
   does not, you may configure the one in Tornado/host/host type/bin.
   See Appendix F of the Tornado User's Guide.

   FLAGS
   -----

   f=0  In this case no special processing is needed.

   f= 0x80 If TFTP will be used to get the boot file.  TFTP can
   be used to download vxWorks but cannot be used  to download
   a file dynamically later.  TFTP is not the same as FTP.
   If your host does not have a TFTP server, you may configure the one
   in Tornado/host/host type/bin.

   f=0x40 If DHCP or BOOTP, (BOOTP is default, unless DHCP
   is configured)  will be used to get an IP address, e
   should be blank.  See Appendix D for additional configuration steps.


   BOOT FILE PATH: RELATIVE OR FULL PATH
   -------------------------------------

   /projpentium/default/vxWorks is the path to reach the boot
   file.  In this example, the Microsoft FTP server has been
   configured with a virtual directory: /projpentium.  The
   actual path is c:\tor2x86\target\proj\newpentium.

   In this case, because the target does not know the full path,
   the target server must be given the full path in Core file
   and symbols.

   TARGET NAME (Ex: tn=mytarget)
   -----------------------------

   Arbitrary name for the target which will be added to the
   target's host table.  vxTarget is the default name.

   STARTUP SCRIPT (Ex: s=/projpentium/script.txt)
   ----------------------------------------------

   Startup script for the target shell.  Commands executed
   before the shell prompt:

   script.txt contains for example:

      cd "zlot:/projpentium/default"
      pwd
      routeShow


2.4 TARGET SHELL TRANSCRIPT
---------------------------
 
At the serial console for the target:

boot device          : elPci
unit number          : 0
processor number     : 0
host name            : zlot
file name            : /projpentium/default/vxWorks
inet on Ethernet (e) : 147.11.41.180:ffffff00
host inet (h)        : 147.11.41.98
user (u)             : mypctarget
ftp password (pw)    : myPassword
flags (f)            : 0x0
startup script (s)   : /projpentium/script.txt


/* BOOTROM image initializes its network modules */

Attached TCP/IP interface to elPci0.
Attaching network interface lo0... done.
Loading... 783808 + 54456 + 53620
Starting at 0x108000...

/* vxWorks runtime image initializes its network modules */
 
Attached TCP/IP interface to elPci unit 0
Attaching interface lo0...done
Loading symbol table from zlot:/projpentium/default/vxWorks.sym ...done


                 VxWorks

Copyright 1984-1998  Wind River Systems, Inc.

            CPU: PC PENTIUM
        VxWorks: 5.4
    BSP version: 1.2/0
  Creation date: Apr  4 2000
            WDB: Ready.

Executing startup script /projpentium/script.txt ...
cd "zlot:/projpentium/default"
value = 0 = 0x0
pwd
zlot:/projpentium/default
value = 26 = 0x1a

Done executing startup script /projpentium/script.txt

/* Network interfaces known to IP */

-> ifShow
elPci (unit number 0):
     Flags: (0x8863) UP BROADCAST MULTICAST ARP RUNNING
     Type: ETHERNET_CSMACD
     Internet address: 147.11.41.180
     Broadcast address: 147.11.41.255
     Netmask 0xffff0000 Subnetmask 0xffffff00
     Ethernet address is 00:50:04:74:1a:9a
     Metric is 0
     Maximum Transfer Unit size is 1500
     1709 packets received; 728 packets sent
     646 multicast packets received
     0 multicast packets sent
     0 input errors; 0 output errors
     0 collisions; 0 dropped
lo (unit number 0):
     Flags: (0x8069) UP LOOPBACK MULTICAST ARP RUNNING
     Type: SOFTWARE_LOOPBACK
     Internet address: 127.0.0.1
     Netmask 0xff000000 Subnetmask 0xff000000
     Metric is 0
     Maximum Transfer Unit size is 32768
     0 packets received; 0 packets sent
     0 multicast packets received
     0 multicast packets sent
     0 input errors; 0 output errors
     0 collisions; 0 dropped
value = 29 = 0x1d

/* Route table: destinations known to the target
 * call routeAdd to add other routes
 */

-> routeShow

ROUTE NET TABLE
destination  gateway        flags  Refcnt  Use Interface
------------------------------------------------------------
147.11.41.0  147.11.41.180   101    0       0   elPci0
------------------------------------------------------------

ROUTE HOST TABLE
destination  gateway        flags  Refcnt  Use  Interface
------------------------------------------------------------
127.0.0.1    127.0.0.1       5      1       0     lo0
------------------------------------------------------------
value = 77 = 0x4d = 'M'

-> hostShow
hostname         inet address       aliases
--------         ------------       -------
vxTarget         147.11.41.180
localhost        127.0.0.1
zlot             147.11.41.98
value = 0 = 0x0

-> arpShow

LINK LEVEL ARP TABLE
destination   gateway         flags Refcnt  Use Interface
-----------------------------------------------------------
147.11.41.98 00:c0:4f:8e:bc:f9 405    0     726   elPci0
-----------------------------------------------------------
value = 75 = 0x4b = 'K'

-> ping "zlot", 2
PING zlot (147.11.41.98): 56 data bytes
64 bytes from zlot (147.11.41.98): icmp_seq=0. time=0. ms
64 bytes from zlot (147.11.41.98): icmp_seq=1. time=0. ms
----zlot PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/0
value = 0 = 0x0

/* mRouteShow shows masks */

-> mRouteShow
Destination  Mask  TOS Gateway     Flags RefCnt Use  Interface
127.0.0.1     0      0 127.0.0.1       5    1    0    lo0
147.11.41.0 ffffff00 0 147.11.41.180 101    0    0    elPci0       0
value = 0 = 0x0

-> devs
drv name
  0 /null
  1 /tyCo/0
  1 /tyCo/1
  6 zlot:
  7 /vio
value = 25 = 0x19
->

/* ls shows files on host zlot's FTP base directory */

-> ls
ctdt.c
ctdt.o...
vxWorks
vxWorks.sym
value = 0 = 0x0

-> pwd
zlot:/projpentium/default
value = 26 = 0x1a

-> ld < helloWorld.o
value = 32491860 = 0x1efc954

-> hello
hello world!
value = 0 = 0x0

-> lkup "statShow"
ipstatShow                0x00133504 text
tcpstatShow               0x00150aa0 text
routestatShow             0x00133cf4 text
icmpstatShow              0x0015181c text
inetstatShow              0x001332d4 text
igmpstatShow              0x00151ba0 text
udpstatShow               0x00150318 text
value = 0 = 0x0

-> udpstatShow
UDP:
        3523 total packets
        3523 input packets
        0 output packets
        0 incomplete header
        0 bad data length field
        0 bad checksum
        3523 broadcasts received with no ports
        0 full socket
        0 pcb cache lookup failed
        0 pcb hash lookup failed
value = 26 = 0x1a

/* Notice tNettask is running */

-> i

  NAME        ENTRY    TID    PRI STATUS  PC       SP   ERRNO
---------- --------- ------- --- ------- ------ ------- ---- 
tExcTask   _excTask  1ee1b28   0 PEND    172216 1ee1a98   0
tLogTask   _logTask  1edf224   0 PEND    172216 1edf190   0 
tShell     _shell    1e4f598   1 READY   131270 1e4f26c   0 
tWdbTask   155bd0    1e5072c   3 PEND    157b6c 1e50680   0 
tNetTask   _netTask  1e9edd0  50 PEND    157b6c 1e9ed78   0 
value = 0 = 0x0
->


2.5 NETWORK DRIVER SELECTION AND CONFIGURATION
----------------------------------------------

Tornado/target/config/BSP directory/target.nr and config.h list
supported network interface cards (NICs).  Some BSPs have only
one while others, like PC targets, have a few to choose from.

BSD44 drivers can be identified by prefix 'if': if_dc.o,
if_fei.o.

END drivers can be identified by suffix 'End':
dec21x40End.o, fei82557End.o.

For PC targets, config.h shows:

   ISA:

   if_eex.o Intel EtherExpress16 (eex) 
   if_esmc.o Ampro Ethernet2(SMC 91c9x chip) (esmc)

   if_ultra.o SMC Elite16 (boot device = ultra)
   ultraEnd.o SMC Elite Ultra END driver (ultra)

   if_elt.o 3Com EtherLinkIII  ISA (elt)
   elt3c509End.o 3COM 3C509 END/SENS driver (elt)

   if_ene.o Novell/Eagle 2000 (ene) 
   ne2000End.o Novell/Eagle 2000 END driver (ene)

   PCI:

   if_fei.o EtherExpress PRO100B (boot device = fei)
   fei82557End.o EtherExpress PRO100B END/SENS (fei)

   ln97xEnd.o AMD Am79C97X PCnet-FAST PCI END/SENS
              driver (lnPci)

   el3c90xEnd.o 3COM EtherLink XL and fast EtherLink 3C90x
      END/SENS driver (elPci)

The vxWorks Reference Manual, Libraries section, has
information under each driver's name regarding configuration
parameters.  

For PC targets, configure ISA cards using the manufacturer's software
so that the IRQ level and the base address match the corresponding
parameters in config.h.  Change the default parameters, if the
card's software detects a conflict.   For both PCI and ISA
cards, use the manufacturer's software to disable Plug and
Play.

For each BSP, the default configuration selects the END driver
for one of the supported network cards.

You need to define the drivers needed by the network cards the
target actually has.  You should undefine unneeded END drivers.

vxWorks will START all defined "END" devices, meaning they will
be physically able to transmit and receive packets, but will
not have IP addresses yet.  Drivers set up their transmit and
receive buffers and connect their Interrupt Service Routines.
"muxDevLoad failed for device entry" error will be printed in
the console if END drivers were defined but the corresponding
cards do not exist in the target.

BSD44 drivers are not started this way.  vxWorks will start
and configure only the boot device so undefining unneeded
drivers is not necessary unless you want to reduce image size.

vxWorks will CONFIGURE only one device: the boot device, or
the device specified by the "other" parameter if the boot
device is a local device (floppy...).  Configuring means that
the interface will be attached to the IP protocol.  The device
will have an IP address and a mask.  The route table will
contain a network route for the device.  The network stack will
respond to pings of that address.

The bootrom and runtime images will first try to find the
driver specified by the boot device in the list of defined END
drivers.  If no match is found, AND support for BSD drivers is
configured, the list of defined BSD44 drivers is searched next.
If a match is not found, error message  "Network interface
unknown" is printed in the console.

If the target has more than 1 network interface, see
APPENDIX C. CONFIGURING ADDITIONAL NETWORK INTERFACE DRIVERS.

2.6 SERIAL CONSOLE SETUP
---------------------

This section explains additional configuration steps needed to
set up the target's serial console whose output goes to the
hyperterminal on the host.

Baud rate and serial port settings must match the corresponding
parameters for the host's serial port.

For Windows NT host: Start->Tornado->vxWorks Com 1 (or vxWorks
Com 2).

On hyperterminal File->properties:

   * Connect using COM 1  (or COM 2)

   * Configure:

     Bits per second 9600
     Data bits 8
     Parity None
     Stop bits 1
     Flow control None

Make null modem cable.  You may need to cross connect TX and RX.

Below are the RS_232 pin configurations for 9 to 9 connectors

Pinout:

RXD (receive data), TXD (transmit data), and GND (signal ground).

        2 TX ----------- 3 RX
        
        3 RX ----------- 2 TX

        5 GND ---------- 5 GND

Cable (Telephone or Ethernet grade) goes between Com 1 on the
target to Com 1 (or Com 2) on the host.


2.7 TARGET SERVER AND WDB AGENT SETUP
------------------------------------- 

TARGET SERVER SETUP
-------------------

The target server's communication mode must match the WDB agent
communication mode.

In Target Server's Properties Backend:

Target Server   WDB agent

wdbserial               WDB serial
wdbrpc          WDB End or Network connection

   1. For WDB serial:

      Make sure target server Baud Rate settings for wdbserial
      match the default settings for the WDB agent
      (WDB_TTY_BAUD = 9600).

      The default WDB port (WDB_TTY_CHANNEL) is 1 which
      corresponds to COMM 2.

   2. For WDB end or network connection mode:

      It is best to start by specifying the target's IP address
      rather than its name.

Relative paths to the image are given to the target for
convenience when setting up the FTP server's base directory for
the target user's name. 

The target server needs to know the path to the image that is
running on the target.  If the target's boot file parameter is
not the full path to the vxWorks image, the  target server must
be given the full path in Core file and symbols:

   Tools->Target Server->Configure
   Target server Properties drop down window, click arrow,
   select Core file and symbols. Enter full path in File: OK


WDB AGENT SETUP
---------------

This section explains the different communication modes the
WDB agent and the target server can use.  It also discusses
conflicts with other libraries, and how the target's
communication mode must match the target server's configuration.

The default configuration for the WDB agent in Tornado 2.0 is to
use the END connection mode so that it can do system mode
debugging over Ethernet.

   a. END CONNECTION MODE

      The WDB agent in END mode attaches as a SNARF protocol
      to one END driver only.  A SNARF protocol sees all packets
      first.  If packets are not destined for WDB, packets are
      given to IP to process.

      If the target has more than one network interface for
      different subnets, WDB packets received on network
      interfaces not snarfed by WDB will be dropped.

      There are problems with this configuration:

      * The WDB agent in END mode attaches as a SNARF protocol
        to the first END driver defined in endDevTbl from
        configNet.h rather than to the boot device (SPR# 28423).
        This would be a problem if there is more than 1 network
        interface defined. The workaround is to make sure that
        the first defined driver in the endDevTbl corresponds
        to the boot device.  For example, for PC targets, the
        FEI entry comes before the ELT entry in the endDevTbl
        from configNet.h.  If both drivers are defined, WDB will
        attach to the fei driver.  If you swapped the order,
        WDB would attach to the elt.

      * WDB agent determines if a received packet is destined
        for itself by inspecting the port field.  WDB may
        inappropriately drop  IP fragments that happen to have
        WDB port (0x4321) in the position corresponding to the
        UDP port field.

        This is SPR# 30194.  There is a workaround.
        target/src/drv/wdb/wdbEndPktDrv.c is given in source.
        In function wdbEndInt please add code below before
        statement:

        if (pUdpHdr->uh_dport != htons(WDBPORT))
            goto wdbEndIntError;

        /**************************************************/ 
        /* Check to see whether the packet is fragmented. WDB
         * does not handle fragmented packets.
         */
        if ((pIpHdr->ip_off & IP_MF) ||
            (pIpHdr->ip_off & IP_OFFMASK))
            goto wdbEndIntError;
        /**************************************************/ 

 

        For the SPRs below, the workaround is to put the WDB
        agent in NETWORK mode or SERIAL mode:

        * WDB END connection mode conflicts with DHCP and other
          protocols that attach as SNARF protocols, including
          API functions such as etherInputHookAdd.  This is
          SPR#27720.

        * For shared memory network, the target server will not
          be able to connect to the WDB agents running in the
          slave targets because the WDB agent at the master
          does not allow the packet to be forwarded
          (SPR# 27815). 

        * There is no END driver available for shared memory
          network (SPR# 25573).

   b. WDB NETWORK MODE

      In this connection mode WDB is a task listening on
      port 17185. This means that any packet received over the
      network from any IP address will be processed by WDB.

   c. SERIAL MODE

      In this connection mode, the default WDB port is COM 2 on
      the target.


2.8 BUILD METHODS OVERVIEW
--------------------------

This section discusses the available build methods in Tornado
2.0: The Tornado 101 Method and the Project Facility GUI.

The Tornado 101 Build Method consists of adding libraries by
defining macros and system parameters in config.h.  This method
is fast to configure but it is difficult to maintain different
images to suit different needs at the same time since there is
only one copy of the main configuration files.

The Project Facility Build Method consists of adding components
using the GUI, defining values under Properties for each
component.  The project facility method takes longer to
configure, but a separate project can be created for each
kernel configuration.  It also helps the user to identify
dependencies between modules.

2.8.1 BOOTROM IMAGES
--------------------
  
BOOTROM images are compiled using the Tornado 101 Build Method
ONLY.  Although, you can build a bootrom image from the GUI,
the build process will be using the Makefile used for the
Tornado 101 method.  config.h must have needed definitions
since the project facility  configuration will not apply at all.
Bootrom images will be integrated to the GUI in future releases.

2.8.2 RUNTIME IMAGES
--------------------

RUNTIME images are built using EITHER the Tornado 1.0.1 Build
Method OR the Project Facility Build Method.

The T101 method and the GUI method are mostly separate, but the
GUI method still relies on some values defined in some BSP files
such as config.h and configNet.h.  If a parameter cannot be
defined within the Project Facility, it must be defined in
config.h.

2.8.3 TORNADO 101 BUILD METHOD 
------------------------------

To enable this option in the T2 Project Facility:
>From the top menu bar:  

   Tools->Options...->Project->Show Tornado 1.0.1 Menu items
   and then Build->Standard BSP Builds->select bsp and image.

The main configuration files are:

   RUNTIME AND BOOTROM IMAGES
   --------------------------

   target/config/all/configAll.h
      This file defines a default configuration appropriate for
      all BSPs  and architectures.  It is recommended that
      configAll.h not be changed. This file contains all
      available configuration macros.  Check the #if FALSE
      section to understand what is excluded from the default
      configuration.

   target/config/bsp dir/config.h
      This file is the place to customize a default
      configuration for a BSP. To determine whether a macro
      should be defined before or after #include "configAll.h",
      check configAll.h.  If there is conditional compilation
      dependent on a macro, then parameters or macros have to
      be defined before #include "configAll.h".  Macros control
      which libraries get added to the image.  Use the command
      grep or findstr in the target/src/config and
      target/config directory to see what the effect of a macro
      is. 

      Among other things, config.h contains the default
      definitions for the following items:

      a. DEFAULT_BOOT_LINE: compiled boot parameters for
         targets with no NVRAM (i.e. PC targets).

      b. Supported network interface drivers for the BSP. 
 
      c. WDB connection mode.

      d. RAM_LOW_ADRS, RAM_HIGH_ADRS.  These numbers determine
         where the bootrom and runtime images get copied in
         memory.  If the image size exceeds the default space
         (for some targets = RAM_HIGH_ADRS - RAM_LOW_ADRS), the
         bootrom code will be overwritten and the target will
         not boot successfully.  Tornado 2.0 images are larger
         since C++ support is included by default.

      e. ROM_SIZE.  Change this value if actual ROM size
         differs. Bootrom images for PC targets must be less
         than 600KB as the processor is in real mode when
         vxWorks boots.

   target/config/BSP directory/target.nr
      This file lists the available Ethernet network interface
      drivers for each BSP and how to produce boot ROMs.

  Makefile
      Each BSP has a single Makefile in the BSP directory.
      This Makefile controls the build process for all images.

   BOOTROM IMAGES
   --------------

   target/all/bootConfig.c.
      This file contains the bootrom image main loop for all
      BSPs. It is one of the modules that make up bootrom_uncmp.
      This file includes target/config/BSP directory/config.h
      which in turn includes target/config/all/configAll.h.

   RUNTIME IMAGES
   --------------

   target/config/all/usrConfig.c
      This file controls initialization of the RUNTIME image
      based on modules defined in configAll.h and config.h.  If
      the network module initialization is defined, usrNetInit
      is called.  usrNetInit starts the network libraries and
      is in target/src/config/usrNetwork.  usrConfig.c includes
      config.h which in turn includes configAll.h.

   target/src/config/usrNetwork.c
      This file contains the network module initialization code.

For detailed instructions please see:

   APPENDIX A. TORNADO 101 BUILD METHOD DIRECTIONS
 

2.8.4 PROJECT FACILITY BUILD METHOD
-----------------------------------

This method is used if vxWorks is configured using the GUI.

The main configuration files are:

   RUNTIME IMAGES
   --------------

   target/proj/project name/projConfig.c
      This file is generated dynamically for each
      project.  This file is equivalent to T101 usrConfig.c

      prjConfig.c controls initialization of all
      modules defined within the GUI. prjConfig.c includes
      config.h at the top:

      /* includes */

      #include "vxWorks.h"
      #include "config.h"

   target/config/bsp/config.h
      At the top of config.h, configAll.h is included.
      Although configAll.h has the same name as the one used in
      the T101 method, the project's Makefile includes a
      different configAll.h:
  
         target/config/comps/src/configAll.h.

      At the bottom of config.h:

      #if defined(PRJ_BUILD)
      #include "prjParams.h"
      #endif

      Parameters defined in the GUI override parameters of the
      same name defined in config.h.

   target/proj/project name/Makefile
      The project facility generates a Makefile dynamically
      for each project.  Object files are placed by default in
      projectname/default directory.

The functions performed by usrNetwork.c have been broken up into
configlettes which can be found in:

   target/config/comps/src/net directory.

Changes to these configlettes would affect all projects.

For detailed instructions please see:

   APPENDIX B.  PROJECT FACILITY BUILD METHOD DIRECTIONS


