The software for the Lego/SN0/Origin2000 Full-Featured System Controller runs under the VxWorks real-time operating system on a x86-based single board computer built by Computer Dynamics Inc. (CDI). Currently, there is no way to cross-compile VxWorks or its applications under IRIX, so actually building FFSC software images must be done on a PC using the tools provided by Wind River (the makers of VxWorks) and optionally their development environment, Tornado. Unfortunately, this doesn't mesh well with the standard SGI build environment and source control tools. This document describes what I have done to get Tornado and IRIX to coexist fairly peacefully and how to build FFSC images in this environment.
Rob Bradshaw
rdb@engr
September 1996
The initial batch of FFSC software has been built using the Wind River Tornado 1.0 product, which incorporates VxWorks 5.3. Tornado runs on a standard PC running Windows 95.
The PC's that we have been using have 133MHz Pentium CPUs, 32MB of memory, 1-2GB of disk, an ethernet interface and one serial port. TCP/IP should be installed on Windows and the PC should be attached to the corporate network. For working with multiple FFSC's, I have found it necessary to add a second ethernet interface (to sit on a private network with the FFSC's) and at least two additional serial ports (one for each FFSC plus a "spare").
The Tornado software should be installed according to the usual directions, though some directories can be removed later on, since they are not needed for our purposes. After installation, you should have a directory tree that includes the following:
| C:\TORNADO\HOST\X86-WIN32\BIN | Build tools |
| C:\TORNADO\SHARE\SRC | Certain source files needed for debugger support |
| C:\TORNADO\TARGET\CONFIG\PC486 | Source files for configuring VxWorks on x86 platforms |
| C:\TORNADO\TARGET\CONFIG\ALL | Platform-independent source files for configuring VxWorks |
| C:\TORNADO\TARGET\H | Header files for VxWorks |
| C:\TORNADO\TARGET\H\MAKE | Makefiles for VxWorks |
| C:\TORNADO\TARGET\LIB\OBJI80486GNUVX | VxWorks libraries for x86 |
| C:\TORNADO\TARGET\SRC\CONFIG | Modifiable source code for configuring VxWorks |
| C:\TORNADO\TARGET\SRC\DRV | User-modifiable source code for VxWorks device drivers |
The portions of the SHARE\SRC, TARGET\CONFIG, TARGET\H and TARGET\SRC directories that are relevant to the FFSC are maintained in an IRIX source tree and can be deleted or renamed on the PC if desired. The HOST and TARGET\LIB directories are not maintained under IRIX and should be retained on the PC. I suspect that the remaining directories could be removed as well, but I haven't tried that yet.
As alluded to above, all modifiable source code, including source code provided by Wind River (VxWorks) and CDI, are maintained in a standard ptools workarea under IRIX. The source tree lives in the "x86/ffsc" subdirectory of the "stand" ism of the current OS release:
and consists of these main subtrees:
| wind | Wind River source code for VxWorks. This consists mainly of clones of the relevant portions of the C:\TORNADO\TARGET and C:\TORNADO\SHARE directory trees from the Tornado distribution. |
| cdi | Source code and other files provided by CDI for the FFSC hardware itself. |
| sgi | SGI-generated source code for the FFSC. |
Most of the files in these directories are in Unix, as opposed to DOS, format which implies that CR-LF pairs have been converted to single LF's and trailing EOF characters (if present) have been removed. The Tornado tools are capable of dealing with Unix format files, though ordinary Windows tools (e.g. notepad, edit) are not. IRIX has two tools, to_unix and to_dos, for converting between the two formats if necessary. Files that are checked into the source tree should generally be in unix format. Note that while the Tornado editor can read unix format files, it always writes DOS format files, so if you edit source files under Tornado, it will be necessary to run to_unix against those files before checking your changes into the source tree.
If the source code lives on an IRIX system and the build tools are hosted under Windows/DOS, then the immediate question is how to get files from one platform to the other. There are NFS packages available for Windows 95, though generally for a fee. A cheaper solution is Samba, a freeware implementation of the Windows SMB protocol that allows IRIX to import and export Windows "shares" (i.e. directories and other resources, such as printers). For IRIX 6.2, a working implementation of Samba can be installed from:
To make an IRIX directory available to Windows, add a section like this to the smb.conf file (in /usr/freeware/lib/samba with the above distribution):
The path should (obviously) be changed to correspond to your own FFSC workarea directory. The user should be a user in your /etc/passwd file that has a password Windows actually matches a user based on their password, not their user name, so it cannot handle a password-less user. If you don't normally maintain a password on your IRIX system, then add a second entry to /etc/passwd with your UID and GID, but then set a password for it.
Once you have added an appropriate section to smb.conf and (re)started samba on your system, you should be able to access the directory specified by path and any subdirectories as:
One major problem with Samba (at this time, anyway) is that it cannot handle mixed-case filenames: all filenames are converted to lower case. This is not normally a problem with Windows/DOS, since filenames are not case sensitive. However, this can cause trouble with makefile dependencies (which are case sensitive), so all #include's in source files should use lower-case filenames. The files in the .../wind and .../cdi directories of the source tree have already been converted accordingly.
Another problem with Samba is that it is not terribly fast, so compile times will tend to suffer if the source code lives entirely under IRIX. To speed things up somewhat, you may want to cache local copies of the .../wind and .../cdi subtrees on the PC, since the contents of these directories probably won't change very often. The makefiles for the FFSC software obtain the locations of the top-level subtrees (wind, sgi, cdi) from environment variables (see below) so it is possible to do this without having to modify any makefiles.
In addition, Windows 95 provides a "briefcase" tool that can make it fairly easy to update these directories on the rare occasions that changes do occur. Rather than creating a directory on the PC to hold a cached subtree, create a new briefcase instead, then use Explorer to drag the contents of the IRIX directory to the briefcase. Later on, if a change is made in either directory, select the briefcase in Explorer and do an "Update All". Windows will detect what files have changed and offer to copy the newer file onto the older one.
The VxWorks makefiles have been rewritten to cope with multiple source directories and to allow building different targets without having to clobber an older target first. In addition, limited-functionality IRIX makefiles are also provided, mainly for the sake of cleanup operations such as "clean" and "clobber". The IRIX makefiles (typically named "Makefile.sgi") are automatically invoked by the VxWorks makefiles when you run "make" under IRIX.
Both the Tornado tools and the various makefiles depend on a number of environment variables being set to function properly. These include:
| WIND_BASE | The top-level Tornado directory, typically C:\TORNADO |
| WIND_UNC | The top-level Tornado directory in "UNC" format, i.e. \\host\share\dir.... For a PC named USPC, with its C: drive shared with the name CDRV, this would be \\USPC\CDRV\TORNADO |
| UNIX_UNC | The UNC path of the FFSC workarea on an IRIX workstation. In the Samba configuration from above, this would be \\UNISCAN\FFSC. |
| VX_SRC | The UNC path of the wind subtree in the FFSC workarea. In the above example, this would be \\UNISCAN\FFSC\WIND, or from a BAT file, %UNIX_UNC%\WIND. |
| VX_LIB | The UNC path of the VxWorks libraries. These are usually in C:\TORNADO\TARGET\LIB, so in UNC format \\USPC\CDRV\TORNADO\TARGET\LIB or simply %WIND_UNC%\TARGET\LIB. |
| CDI_SRC | The UNC path of the CDI source subtree. \\UNISCAN\FFSC\CDI in this example. |
| SGI_SRC | The UNC path of the SGI source subtree. \\UNISCAN\FFSC\SGI in this example. |
| BUILD_DIR | The UNC path of a directory in which object directories and final images should be stored. This would typically be the $WORKAREA directory under IRIX though for performance purposes you may want to cache this on the PC and copy over the top-level makefile from IRIX. |
| WIND_REGISTRY | The TCP/IP hostname of a PC running the Wind River registry server. Normally, this would be your PC. |
| GCC_EXEC_PREFIX | Required by the Tornado build tools. This should always be C:\TORNADO\HOST\X86-WIN32\LIB\GCC-LIB |
| WIND_HOST_TYPE | Also used by the Tornado build tools. This should always be x86-win32. |
A batch file that sets all of these variables can be found in the IRIX source tree in protoffscvars.bat. Copy this file to a convenient location on your PC (perhaps renaming it to ffscvars.bat) and edit it to match your configuration. You may want to CALL it from your AUTOEXEC.BAT file; if not, you will need to run it before invoking Tornado.
Unfortunately, this many environment variables may cause Windows to generate "Out of Environment Space" errors. If that happens, it will be necessary to increase the size of your environment space by adding the option /E:1024 to the COMMAND.COM command line. ("Consult your owner's manual for details.")
From the top-level FFSC directory, the default make target is to build an FFSC software image of some kind. The exact kind of image that is built depends on the settings of several MAKE variables, which would typically be set on the command line that invokes make:
| no variables set | Build a normal network-bootable VxWorks image and separate symbol file. |
| STANDALONE=1 | Build a standalone VxWorks image, with the symbol table built in to the image itself. This is *not* a network-bootable image; it must be flashed onto the FFSC. |
| STANDALONE=1 NETBOOT=1 | Build a network-bootable standalone VxWorks image. The symbol table is built into the image itself, but the load address is set so that the image can be booted over the network. |
| PRODUCTION=1 | Build a production version of the FFSC firmware image. This is similar to a STANDALONE image, except that the symbol table and other debugging features (e.g. the target shell) have been removed so that the image is smaller. |
| BOOTROM=1 | Build a bootrom image. Once this image is flashed into the FFSC, the FFSC will try to boot the actual VxWorks image over the network. |
| BOOTROM=1 FFSC_NUM=num | Build a bootrom image for a specific FFSC. This simply changes the naming convention for the object directory and final image of the bootrom, though it can also be used to tweak the bootline parameters if desired (see below for info on the bootdefs file). |
There are a number of specific targets that can be invoked as well:
| vxworks | Same as make default |
| vxworks.st | Same as make STANDALONE=1 |
| bootrom_uncmp | Same as make BOOTROM=1 |
| depend | Generate dependencies for the selected image |
| dependall | Generate dependencies for all known images (i.e. all 6 of the images described above) |
| clean | Clean up object files and generated source files |
| clobber | same as clean, but also deletes final targets and dependency files |
| deltree | delete the object directory |
| rmtarget | remove the final target file(s) only |
| srcclean | erase cruft (such as *~ files) from *source* directories |
| sterile | like srcclean followed by a clobber and rmdir of each possible object directory. |
After a make sterile a p_check -w should only show bootdefs and ffscvars.bat (if present)
Building a bootrom image requires a fair amount of information about the current environment, such as the name and address of the host PC and the path name of the VxWorks image on the host machine. This information is obtained from a file called bootdefs in the top-level directory of the workarea. To create a bootdefs file, simply copy the template file protobootdefs (which is part of the source tree) to bootdefs and edit it to match your current configuration. If you are working with two or more FFSC's, you can examine the contents of the FFSC_NUM variable and adjust several of the values (such as the target IP address) using the GNUmake ifeq command.
Because the FFSC firmware is not built under IRIX, it cannot be formally built for releases by the build group. Instead, an Official Production Image is built and checked into the appropriate irix source tree in uuencoded form. The standard irix build process can then take over and include a binary version of the image in the standard irix distributions (typically in /usr/cpu/firmware/ffscfw.bin).
The steps required to do all of this are split up between the PC and a standard ptools workarea under unix:
Rob Bradshaw Last modified: Thu Oct 3 23:29:55 PDT