VxWorks on Nova

Carl Schumann
1 May 2000


Introduction


This document details the state of the VxWorks installation on nova.fnal.gov.   The document will also explain the goals which lead to the current state along with the administrative dealings that have occurred with Wind River Systems regarding the nova VxWorks installation.  This document deals principally with the administration of Tornado 2.0/ VxWorks 5.4.   There are four installations of VxWorks on nova - Tornado 1.0.1 for 68k, Tornado 2.0 for 68k, Tornado 1.0.1 for PowerPC,
and Tornado 2.0 for PowerPC.

Goals

The current state of VxWorks on nova was largely a result of trying to satisfy the following goals.   How each goal was achieved is presented along with the presentation of the goal itself.
 

Project Facility Issues

One will notice that the vxworks/builds directory in CVS contains two workspaces and several projects.   This is somewhat annoying since these builds are intended to be the same configuration just for different platforms.  If one wants to add a kernel option to the standard build one must update the configuration for each project, which is sure to introduce consistency problems.   Unfortunately, this is the best one can do with the project facility.   If the WRS environment variables on the host that select a processor do not match the processor of the selected workspace, project will issue a warning.  So a workspace is needed for both processors.   A separate project is needed for each board because the Makefiles used by the project facility use a define, BSP_DIR, which can only reference a single BSP.   Also some boards/BSPs do not support some options which one would like in the standard kernel where possible, e.g., spy.   Even the 4MB and 16MB mv162 kernels required different projects, because memory size is kernel configuration option and only one set of kernel configurations is allowed per project.   A project allows multiple builds, but such builds may only differ by compiler switches, etc. not by kernel configuration options.
 

Administrative Issues

While setting up VxWorks I have maintained two files, Log and TSRs, on nova both in ~vxworks.   Log is a reasonably detailed log of items relating to vxworks on nova.   TSRs is log of TSRs (Technical Support Requests) submitted to WRS.  Some TSRs are still not resolved, the next administrator may want to follow-up on such TSRs.
 

Remaining Issues

On fecode-bd, I have installed standard downloadable kernels for all platforms given above.   My plan was to run these new kernels on my FE systems, SWIC and vacuum.  After the basic correctness of the new kernels was verified, other FE systems could be upgraded to these standard 5.4 kernels.   (It is possible/probable that other systems will create other issues for the standard kernels, but it seems best to resolve them one at a time.)  However, WRS has changed its PCI support from VxWorks 5.3.1 to 5.4.   This breaks the sld library which both of my systems use, so I am unable to progress any further until this issues is resolved.  I have contacted WRS about this and was assigned TSR 157622.  This TSR has not been resolved yet.

Security, Privacy, Legal