Setting up the Networking Environment

• A BOOTP/DHCP server to provide information about the networking environment (including the servers mentioned below). A sample dhcp configuration file (for the Internet Software Consortium's implementation) can be found here.
  
• A TFTP server for supplying the boot image. The TFTP server can also be used as a general remote fileserver since RTEMS supports a TFTP filesystem. A TFTP server should be  run with the '-s /afs/slac/package/rtems/4.6.2' option. This makes all files under '/afs/slac/package/rtems/4.6.2' available under the virtual '/TFTP/BOOTP_HOST/' directory on the target. The special string 'BOOTP_HOST' requires the BOOTP and TFTP servers to be the same host. Other TFTP servers can be addressed by substituting 'BOOTP_HOST' by the server IP address in 'dot'-notation. Note that a consequence of the limitations of the TFTP filesystem is that the 'pwd()' command does not work it is hence not possible to determine the current working directory. The shell's 'TAB'-completion does not work for the same reason.
  
• A NFS server. Although the TFTP filesystem can be used for simple purposes, it is quite cumbersome and has reduced functionality (no 'stat', no file creation, no 'seek', no directories, symlinks etc.). On systems with limited memory, using NFS can be imperative as the run-time loader needs to copy object files from TFTPfs to RAM due to the TFTPfs limitations. Note that a TFTP server is still needed for booting since most firmwares and GRUB do not support booting from NFS. The pre-built software assumes the NFS server to export '/afs/slac/package/rtems/4.6.2'. Additional servers/directories can be provided.
  
• One or more DNS servers (optional).
• One or more NTP servers (optional - mandatory for EPICS, however).

How the Boot Process Works

1. The target firmware (pcX86: GRUB) needs to learn its network configuration. Some firmwares can use BOOTP and hence the same BOOTP service as the final system. Other firmwares (e.g., a vxworks bootrom with no BOOTP client functionality) require manual intervention.
2. The target firmware contacts the TFTP server, loads the GeSys image into memory and transfers control to GeSys. At this point the network configuration 'learned' in step 1. is 'forgotten'.
3. RTEMS/GeSys initializes and contacts the BOOTP server (again) to figure out the networking configuration.
4. GeSys retrieves the boot-file name and substitutes the file name extension by '.sym'. It then loads the system symbol table file and initializes Cexp.
   NOTE: If GeSys was compiled with a built-in symbol table, this step is omitted.
5. GeSys retrieves the boot-file's directory path (which maps to some remote file either on TFTPfs or NFS) and makes it the current directory ('chdir()' call).
6. GeSys executes Cexp to evaluate a 'system script', st.sys, (if found). This script can be used to perform generic initialization/setup that is common to all target instances.
7. GeSys evaluates the BOOTP option 129 (RTEMS extension: 'command line') and copies all 'KEY=value' pairs into the environment where they can be retrieved by applications by ordinary 'getenv()' calls.
8. GeSys tries to find an environment variable 'INIT' (which can be set via BOOTP option 129) by calling 'getenv("INIT")'. If this environment variable is defined, it should define the (absolute) path to a further (target machine specific) initialization script. If the script is found, GeSys changes directory to the script location and executes it.
9. Gesys enters the Cexp shell in interactive mode.