5.5 Remote targets supported

The DejaGnu distribution includes support for the following remote targets. You can set the target name and the connect mode in the ‘site.exp’ file (using the Tcl variables ‘targetname’ and ‘connectmode’, respectively), or on the runtest command line (using ‘--name’ and ‘--connect’).

AMD 29000, with UDI protocol

Configure DejaGnu for target ‘a29k-amd-udi’. (Cygnus configure also recognizes the abbreviation ‘udi29k’.) Then, to run tests, use the runtest target name to specify whether you want to use a simulator, or a particular hardware board. The particular string to use with ‘--name’ will depend on your UDI setup file, ‘udi_soc’ (if ‘udi_soc’ is not in your working directory, the environment variable ‘UDICONF’ should contain a path to this file). For example, if your UDI setup file includes these lines:

iss   AF_UNIX  *   isstip -r /home/gnu/29k/src/osboot/sim/osboot
mon   AF_UNIX  *   montip -t serial -baud 9600 -com /dev/ttyb

You can use ‘--name iss’ to run tests on the simulator, and ‘--name mon’ to run tests on the 29K hardware. See the manufacturer’s manuals for more information on UDI and ‘udi_soc’.

The default connect protocol is ‘mondfe’ with either back end. mondfe is the only shell DejaGnu supports for UDI targets. mondfe is an AMD specific monitor program freely available from AMD.

Warning: This target requires GDB version 4.7.2 (or greater). Earlier versions of GDB do not fully support the load command on this target, so DejaGnu has no way to load executable files from the debugger.

Motorola 680x0 boards, a.out or COFF object format

Configure DejaGnu for any remote target matching ‘m68k-*’.

Warning: Most ‘m68k-*’ configurations run all tests only for native testing (when the target is the same as the host). When you specify most of these targets for a cross configuration, you will only be able to use tests that run completely within the host (for example, tests of the binary utilities such as the archiver; or compiler tests that only generate code rather than running it).

To run a.out or COFF binaries on a remote M68K, you must configure DejaGnu for a particular target board. ‘m68k-abug’ is an example. (In general for an embedded environment, because it does not have absolute addresses, a.out is not a good choice for output format in any case; most often S-records or Hex-32 are used instead.)

Motorola 68K MVME 135 board running ABug boot monitor

Configure for ‘m68k-abug-aout’ or ‘m68k-abug-coff’ (as a target). This boot monitor can only download S-records; therefore, the DejaGnu tests for this environment require a linker command script to convert either output format to S-records, setting the default addresses for .text, .bss, and .data.

With this configuration, the default for ‘--connect’ is ‘tip’. ‘tip’ is the only communications protocol supported for connecting to ‘m68k-abug-*’ targets. ‘tip’ uses an ASCII downloader (the ~put command) to load S-records into the target board. The ‘--name’ string must be a machine name that tip understands (for example, on some tip implementations it must be an entry from the initialization file for tip; this file is sometimes called ‘/etc/remote’).

See your system documentation for information on how to create new entries in ‘/etc/remote’. (Some UNIX systems are distributed with at least one default entry with a name resembling ‘hardwire’; if your system has one, you can edit it, or make a modified copy with a new name.) When you have a working ‘/etc/remote’ entry abugtarget, you should be able to type ‘tip abugtarget’, and get the prompt ‘135ABUG>’ from the board. Use the same abugtarget string with ‘runtest --name’.

Motorola IDP board running the rom68k boot monitor

This is the same in functionality as the MVME board running the BUG boot monitor. Only the monitor commands and the addresses are different.

VxWorks (Motorola 68K or Intel 960)

Configure DejaGnu for either ‘m68k-wrs-vxworks’ (abbreviated ‘vxworks68’) or ‘i960-wrs-vxworks’ (abbreviated ‘vxworks960’). Since both targets support IP addressing, specify the network address (for example, a host name from ‘/etc/hosts’) with ‘--name’.

The default connect protocol is ‘rlogin’, but you can use any of ‘--connect rlogin’, ‘--connect telnet’, or ‘--connect rsh’.

Test scripts need no special code to load programs into these targets; since VxWorks supports NFS, all you must do is ensure test programs are on an exported filesystem.

When you compile for VxWorks, use the linker ‘-r’ option to make the linker output relocatable—at least if you want to use library routines. Many standard C routines are included in VxWorks; often no additional libraries are needed. See your VxWorks system documentation for additional details.