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