This page provides a repository for information about using the WRS Tornado environment and the vxWorks 5.x RTOS with EPICS that doesn't really belong anywhere else on the EPICS site. If you discover any other information that ought to go on this page, please let me know.
Note that there is a separate page provided for users of vxWorks 6.x and Wind River Workbench.
There is also a reasonably good Tornado 2.0 FAQ available on the web, mostly comprising answers to questions posted to the comp.os.vxworks news group.
According to the Tornado 2.2 release notes, you cannot install multiple host and/or target architectures in the same directory.
See this page for information building vxWorks target code on Linux.
Ron Sluiter has succeeded in building Base R3.13.7 against Tornado 2.2, but said in an email to tech-talk that in order to do so he had to remove the switch -nostdinc from the EPICS configuration file <base>/config/CONFIG.Vx. Base R3.14.x should build on Tornado 2.2 without change.
VxWorks 5.4.x will not be supported by future EPICS Base 3.15 releases. The GNU C++ compiler provided with 5.4.2 is too old, you will have to upgrade to at least vxWorks 5.5 or preferably vxWorks 6.x.
With Tornado 2.0.x it is possible to install multiple host and target architectures to the same location, and this is probably better than keeping them separate (Tornado 1.0.1 allowed some combinations, but not all). It is definitely not a good idea to mix difference versions of Tornado (for different architectures) in the same location.
The following patches have been found to fix certain problems with Tornado 2.0 and ought to be installed at all EPICS sites using the indicated architectures or board types. Patches must be downloaded from WRS's Customer Support website:
See the document Configuring Tornado 2.0.x for EPICS for some information on how to configure your vxWorks image to be able to load and run EPICS.
Some additional points to note about the Tornado 2 configuration:
The network memory buffer configuration for Tornado 2.x is significantly different to that for Tornado 1.x and earlier, because of the new network stack that is uses. The new configuration process requires that the complete number and size of these buffers be set at compile time (actually these numbers can be changed early in the BSP startup, but not afterwards); the old stack could dynamically grow the number of mbufs it used as necessary, so the initial configuration was not particularly critical, unlike with the new stack. The WRS defaults provided in Tornado 2.x are too small for most operational EPICS IOCs.
The official WRS method of configuring the network stack is described in section 4.6.3 Network Memory Pool Configuration of the vxWorks Network Programmer's Guide (that section number is from the vxWorks 5.4 edition, for the vxWorks 5.5 edition it's 4.3.3). APS and SNS have both developed their own alternatives to this fixed approach which permit the number of buffers to be selected at boot time from the vxWorks boot parameters. At APS we provide two configurations that are selected between by one of the bits in the boot flags according to the loading on that particular IOC. The actual numbers of buffers used are as follows:
Parameter Value (light) Value (heavy) Data Pool clDescTbl [] NUM_64 125 250 NUM_128 400 400 NUM_256 50 50 NUM_512 25 50 NUM_1024 25 25 NUM_2048 25 25 NUM_NET_MBLK 800 1200 NUM_CL_BLK 650 800 System Pool sysClDescTbl [] NUM_SYS_64 256 1024 NUM_SYS_128 256 1024 NUM_SYS_256 256 512 NUM_SYS_512 256 512 NUM_SYS_MBLK 1024 3072 NUM_SYS_CL_BLKS 1024 3072
If the shell on an MVME1xx IOC (68k family) ever runs continuously without ever relinquishing control to lower priority tasks for more than 1.5 seconds, you might get the error message
interrupt: ei0: reset
This comes from the ei ethernet driver whenever tNetTask takes longer than 1.5 seconds to process some incoming packets, and may or may not be serious - at iocInit it appears to be benign (it often occurs in dbLoadRecords with large databases), but if it occurs later there are reports that it can cause a complete hang. If you're not using an NFS filesystem I would suggest switching to this if possible as it might solve it, otherwise you can temporarily reduce the priority of the tShell task at the beginning of the startup script are restore it again afterwards as follows:
taskPrioritySet(0,60) ... taskPrioritySet(0,1)
An IP packet is being transmitted, and based upon how it matches network interfaces' IP addresses and mask, an outgoing interface is selected, at which point the interface driver calls arpresolve to get a MAC address for that IP address, either by sending an ARP request, or by using a cached entry. At that point, if the ARP code, looking for an ARP cache entry, finds that this particular IP address has a specific routing entry which is not an ARP entry, it will return that particular error. Since ARP uses has a common mechanism with the IP routing table, there could not be a routing entry and an ARP entry for the same destination IP address at the same time. One possible reason for this is if an ICMP Redirect is received for a particuar IP address, which would be considered "local" if mathcing its address to the network interface's IP address and mask. mRouteShow() at the time of this error should pretty much paint the picture in bright colour.
There can be a network reliability problem with Tornado 1.0.1 on the mv2700 through certain types of 10/100baseT media. A quick way to resolve this problem (rather than getting a patch for Tornado 1.0.1 from WRS) is to change the setting of DC_MODE in the config/mv2700/config.h file from 0x08 to 0x18. This puts the driver into Full Duplex mode. Note that this setting must be correct for the network port you're using, so you might need two boot files if you have both full- and half-duplex ports.
There is a separate page discussing the specific problems associated with using PowerPC CPUs under vxWorks/Tornado.