New Version (02/08/99)

• It is no longer necessary for each product that is loaded to the VxWorks board to have a VxWorks flavor declared to ups. Instead, just the normal host version setup is used.
• Some of the host setup scripts output to the terminal. This would cause VxWorks boards to hang while booting. Sending the setup output to /dev/null did not work with the cshell. Hence, the system now uses the bash shell. See the instructions at the end of this page.

The original scheme of boot scripts and problems

Most startup scripts have a lot in common: they establish network routes, load fision, robin, and cdfvme_common. The differences are in what network routes are established (based on location), and what version of fision/robin etc. to load. This partly depends on the CPU architecture, and also there are sometimes reasons to load some version besides the default. Also, in the present organization there is a separate startup script directory for each board type and VxWorks version. This exacerbates the above problems.

New system

To remedy this, we have implemented a system where there are a very small number of main startup scripts, like a few. The main startup scripts will internally refer to separate scripts to load and start fision, robin, etc. These scripts will in turn internally refer to specific directories in fision, robin, etc. via environment variables. Thus for example a single startup script can load any version of fision etc., including the CPU architecture dependence, provided the correct environment variables have been set. These environment variables are set by the .bashrc for user vxworks, which is invoked on any file access that uses the network file driver. The scheme makes heavy use of ups II.

In the new scheme, the .bashrc will determine the target node via the REMOTEHOST environment variable. It will then do a setup command of the "vxboot" product with a qualifier based on the node name and CPU architecture. There could either be one qualifier option per board, or per block of similar boards. The "vxboot" product will contain table files for each possible qualifier. At the beginning of the file, is listed the appropriate VxWorks version, and the board type and CPU architecture. The table file then sets up the desired versions of fision, robin, cdfvme_common, etc. etc. These are then used by the fision etc. startup scripts.

Note that the above requires that there be an instance of the vxboot product declared to ups for each possible qualifier.

The last part of the global startup script invokes a custom script, giving one the opportunity to add things on a board specific basis. The default is to invoke a null script, if something else is desired then the environment variable CUSTOM_STARTUP should be set in the board table file. However, it is highly desirable that all products of a generally useful nature be put in the default startup script. Only when testing a new product that may cause serious problems when loaded should the CUSTOM_STARTUP option be used.

Implementation

• ~vxworks/.bashrc contains the .bashrc for user vxworks

• ~vxworks/boot/front-end contains the main startup script startupb.all and all the sub-scripts to which it refers.

• /cdf/onln/code/cdfprod/vxboot/ups contains the ups table files

• The implementation gives examples of both a table file for each processor, as well as one for a block of processors (b0_cal).

Issues with the new scheme

Possible drawbacks include:

• Increase in time required for file access. .bashrc, setups.sh, and the various internal setups are executed on the host on each file access. There are many file access during booting. When b0sgh was the host, the additional time required to boot was significant. However, when booting from the much faster b0dau30, this is not an issue.

• It would be really nice if there was some way of automatically determining the CPU architecture. I am not able to figure out a way, suggestions are welcome. The network file access via rsh passes no context aside from REMOTEHOST. Also, the VxWorks node does not run a standard rshd or equivalent such that the host could query the target.

• It has been experimentally determined that if messages are printed by the .bashrc and setups it invokes, sometimes the board will hang during boot. Hence, the .bashrc file directs all output to /dev/null. For some reason this did not work properly under csh, which is the reason to using bash as the default shell for user vxworks.

• Errors in setup files/ups tables can cause things not to boot. This has also experimentally been determined... Again, care is required.

• The system works best when new packages are more formally "productized" at an early stage. This is considered a good thing...

• It is still a somewhat complicated system and there is more than ample opportunity to mess things up. However it is hoped that as the system grows this will at least be much more manageable than the current system.

Steps to add a new processor/boot script

• Create a table file preferably based on one of the table files in ${VXBOOT_DIR}/ups. Assume in the example below it is named it newboot. Use one of the files xxxxb.table, such as b0_calb.table. These are for use with the new bash shell implementation. Files such as b0_cal.table was for use with the original cshell implementation, are not compatible, and should not be used. A single table file should support both 68k and Power PC processors. This means than any new loaded products must be built for both architectures. This is mandatory. We must be able to use Power PC and 68k processors interchangably.

  The most common modification would be selecting a different network startup for processors outside of B0, selecting a different version of some product for test purposes, or selecting a different custom startup script to be executed at the end of the boot.

  Make sure that:

  • The qualifiers in the table file are changed from the original name to "newboot" (or whatever is the selected name)
  • Any scripts refered to in a modified CUSTOM_STARTUP must actually exist.
  • All table files must reside in ${VXBOOT_DIR}/ups so they may be easily located in case global changes are necessary.

• Declare instance(s) of vxboot:
  • setup vxboot
  • ups declare -c -z /cdf/onln/code/cdfprod/upsdb -r ${VXBOOT_DIR} -M ups -m newboot.table -f NULL -q "newboot:68k" vxboot v1_0
  • ups declare -c -z /cdf/onln/code/cdfprod/upsdb -r ${VXBOOT_DIR} -M ups -m newboot.table -f NULL -q "newboot:ppc" vxboot v1_0

• Add the appropriate setup in the switch statement in ~vxworks/.bashrc:
  • setup -q newboot:68k vxboot for the 68k version
  • setup -q newboot:ppc vxboot for the ppc version

  Make sure there are no syntax errors in .bashrc!

• In the VxWorks board boot parameters (accessible via the "bootChange" command):
  • Set the username to vxworks (not vxworksb)
  • Set the startup script name to boot/front-end/startup.all or boot/front-end/startup.all.flash as appropriate.