Next: Running Test Suites Up: Running a Kernel Previous: Mach 3 x-kernel

Scout (Alpha standalone)

Booting

Currently, the standalone kernel can be booted via network only. The Alpha firmware supports booting from the network via BOOTP (to get the boot parameters) and TFTP (to download the boot file). That is, to boot the standalone kernel, you need to designate some machine (other than the one you want to boot) as your bootserver. This machine does not have to be an Alpha. Anything supporting BOOTP and TFTP should work. You'll need to consult the bootserver's system documentation to find out how to setup a boot server. Typically, this involves enabling the bootpd and ftpd daemons and adding an entry to the /etc/bootptab file. For example, we use the following entry to boot one of our Alpha machines:


piston.cs.arizona.edu:\
hd=/usr/local/boot:bf=xkernel.boot:ht=ethernet:ha=08002BBAAB3E:\
        hn:vm=rfc1048:ip=192.12.69.168:bs=auto:
To boot a kernel, you need to copy the file xkernel.boot that was generated during the build process into the bootserver's directory. This directory is defined via the hd capability and in the above example is /usr/local/boot

Once a bootserver is setup, the Alpha machine can be booted from the console prompt. The boot command syntax is (square brackets indicate optional items):

boot ez [ -fl bootflags ] [ -fi "filename " ]
To boot the default file (defined via bf capability in /etc/bootptab), you simply type ``boot ez.'' The bootflags can be any string of the characters described in the table below:

The -fi option can be used to boot an alternative kernel. Any file in the bootserver's directory can be specified (relative pathname). Notice that the filename must be enclosed by double quotes.

Specifying x-kernel Command Line Options

After booting a kernel with the i bootflag, an x-kernel command line string can be entered at the scout: prompt. This is useful when running one of the test protocols (see page ). For example, when running udptest, a typical command line is (user input in bold-face):

scout: -testudp -c192.12.69.54 -trips=1000
This command line requests that udptest be run as a client, that the server is running on the machine with IP address 192.12.69.54, and that each test should exchange 1000 messages.

Using GDB

GDB's remote debugging facility can be used to debug a standalone x-kernel over a serial line cable. Once GDB is attached to a kernel, debugging works just like debugging any other program. For example, it is possible to interrupt a running kernel, set breakpoints, inspect variables and so on.

For remote debugging, it is necessary to have an additional Alpha machine running OSF/1 (the host machine). This machine needs to be connected over a serial line cable to the machine that you wish to debug (the target machine). The serial line cable on the target machine must be connected to communications port 1 (aka /dev/tty00). On the host machine, it can be connected to either of port 1 or 2. For now, let us assume it is connected to port 1 on both machines. The serial line parameters are fixed to 38400 bps, 8-bits, no parity. GDB must be of version 4.12 or newer. Older versions of GDB cannot handle remote debugging of 64 bit architectures.

To debug a kernel, proceed as follows:

  1. Boot the file xkernel.boot on the target machine, specifying bootflag k. The console on the target machine should display the message:
    
    kgdb: waiting for remote gdb to connect...
  2. On the host machine, cd to the build directory in which you built the kernel (e.g., build/example).
  3. On the host machine, startup GDB as follows:
    $ gdb xkernel
    (gdb) set remotebaud 38400
    (gdb) target remote /dev/tty00
    NOTE: GDB is invoked with xkernel, not the bootable file xkernel.boot.
After entering the ``target remote'' command, GDB should return with the prompt. It is now possible to use the normal GDB commands to set breakpoints, inspect source code, and so on. The kernel can be resumed with the continue command.

Interrupting with GDB

If GDB is attached to a running kernel, it is possible to interrupt it by typing a single Ctrl-C in GDB (i.e., on the host system). It is often necessary to find the address at which the CPU was executing prior to the interruption. This can be achieved by executing GDB's up command until reaching the frame in file alpha_locore.s. In this frame, the stack pointer (GDB variable $sp) points to the saved CPU state. The saved state can be printed with the command:


p/x *((Alpha_Saved_State*)$sp)
The command will print the Alpha's CPU registers (except for the floating point registers). The program counter is stored in field pc. So to find the source line at which the CPU was executing, you can type:

list *((Alpha_Saved_State*)$sp)->pc

Attaching GDB to a Running Kernel

It is also possible to attach to a running kernel that has not been started with bootflag k. To drop a running kernel into GDB mode, all you need to do is send a single Ctrl-C character over the serial line. This is most easily done by a communications program such as Kermit. For example:

$ kermit
C-Kermit> set line /dev/tty00
C-Kermit> set speed 38400
C-Kermit> connect
At this point, type Ctrl-C once. After that, the kernel should respond with a string looking similar to this:

$T050f:0000002000000000;1e:90beff0100fcffff;...
Now you can exit Kermit (typically by typing ``Ctrl- c quit''). It is then possible to start GDB and attach it to the target system in the usual manner (as described above).



Next: Running Test Suites Up: Running a Kernel Previous: Mach 3 x-kernel


Tue Nov 29 16:28:56 MST 1994