Booting and Running an IBM X-station 130
in a Linux Environment

    The IBM X-station 130 is a very nice little X-server (terminal) which boots its operating code and retrieves its font (typeface) information from another server, usually one running IBM's AIX operating system. This document will show the reader how to run the X-station 130 without benefit of a companion AIX server. Much of the information used in this document was taken from a manual on IBM's WWW site, The IBM Xstation Handbook . The rest of it was acquired by experimentation with the X-station 130 in my collection.

    Note that you, the reader, must acquire the X-station operating code on your own; I cannot assist in this as I would be breaking all manner of license agreements. That said, the code may be lifted from any RS/6000 which has the "x_st_mgr" product on it.

    The "IBM Xstation Handbook" strongly suggests that the 130 requires an AIX companion to serve the 130's boot code and fonts and provide login services. However, it is possible to run the 130 in a completely non- AIX environment. My intent with this document is to demonstrate to hobbyists, and others who may have a 130 but no systems capable of running AIX, that the 130 can be successfully put to use.

    The 130 can be configured to boot over the integral Ethernet interface, a SLIP line or, if the machine is so equipped, a token- ring link. I boot mine over Ethernet because that's what my LAN, for the most part, runs over. I haven't tried booting it using the optional token- ring card, nor SLIP. This document will cover Ethernet only, although the others should be fairly self- explanatory.

    The X-station 130 supports both AUI-style (10-Base5, aka "thick-wire" Ethernet) and 10-Base2 ("thin-wire") Ethernet; there are internal jumpers that are set depending on which style of attachment one desires. The jumpers are on a block labelled "JP2". JP2 may be found by opening the machine up and, holding the machine with the power switch towards you looking toward the rear of the motherboard (the "planar" in IBM parlance), is located near the AUI (15-pin) connector. Thin-wire is selected by placing all the jumpers to span the "middle-to-rear" pins and thick-wire by spanning the "middle-to-front" pins. Note that the machine will not talk on the network if the jumpers are incorrectly set.

    Most environments today will probably use 10-BaseT transceivers that plug into the 15-pin AUI connector. This calls for the "thick-wire" setting described above.

    There are a number of different ways to get the 130 to work, "out of the box" in a non- AIX environment. Here are a few of them:

    In a statically- configured environment, the 130 must be properly configured to contact the machine which stores the 130's boot code and font information. This is done in the setup screens which are accessed by pressing <F12> during the boot procedure. In this instance all the boot- time information must be provided. The Xstation-130 has a NVRAM (Non- Volatile RAM) subsystem in it, so it'll store the configuration across power- downs.

    When the machine is first powered on, it will attempt to boot to the last host it was configured to contact; to interrupt this process, and enter the network configutation screens, one presses the <F12> key. This will place the operator at the first, or SLIP, configuration screen. Mine, in the static configuration, looks roughly like this:

Network Setup             Page 1


Primary Network..................Ethernet

Enable SLIP......................NO
   Serial Port...................SERIAL 1
   Baud Rate.....................9600
   Terminal Internet Address.....
   Host Internet Address.........
   Subnet Mask...................
   Dial String...................
   Disable Bootp.................YES
      TFTP File Name.............
      Tag Field..................


    Advancing to the next page (with <Page Down>), the second page of configuration in my setup contains:

Network Setup             Page 2


Ethernet/IEEE 802.3 ..............Automatic

Gateway Internet Address .........
Terminal Internet Address ........
Host Internet Address ............
Disable BOOTP ....................YES
   TFTP File Name ................/var/tftp/Xstation/boot/bootfile4
   Tags Field ....................


    The "Terminal Internet Address" is the IP address of the X-station 130; the "Host Internet Address" is the IP address of the server which contains the 130's boot code and fonts. Note that this need not be the same machine as the login server. The 130 is capable of gathering this information via bootp, for a discussion of that mode, see the Dynamic Configuration section.

    The "TFTP File Name" above points to the name of the secondary boot loader which is loaded into the 130 which subsequently loads the main X-server operating code.

    On the boot server, I enabled TFTP in the /etc/inetd.conf file by placing into it a line like:

tftp   dgram  udp   wait  root  /usr/sbin/tcpd  in.tftpd /var/tftp /tmp

    Note that this makes use of an IP wrapper so I can control who gets into my TFTP server. As TFTP is incapable of any sort of authentication, it's considered prudent to control who and what gets access to the server, and even then chroot them to someplace safe. Linux is actually quite good about this; the above entry will only allow TFTP access to the "/var/tftp" and "/tmp" directories. The code and fonts live in a subdirectory of the "/var/tftp" directory. A paging file is created by, but seems unused by, the 130 and lives in "/tmp".

    In that "/var/tftp" directory tree are all the things that the 130 needs to run efficiently and be happy. See the disclaimer above about the server code.

    The fonts can be had by gunzipping the pcf font files on a Linux machine and building the appropriate "fonts.dir" and "fonts.alias" files. This is what I have in "/var/tftp" on my boot server:


boot/           <--- Boot and Operation code directory
fonts/          <--- X Fonts directory
rgb.txt         <--- Colour descriptor database*         <--- Logon startup commands

bootfile4       <--- Xstation bootstrap code
x11xor4.out     <--- X11R4 server code    <--- Server configuration data (see below)
keymap.kj       <--- Kanji keymap file
keymap.wt       <--- Keymap file (locale unknown)       <--- US keymap file
msg             <--- (empty in my configuration)

Xstation/fonts: <--- Standard X11 PCF fonts
10x20.pcf      clR6x6.pcf     helvBO14.pcf   lubBI10.pcf    ncenI24.pcf
12x24.pcf      clR6x8.pcf     helvBO18.pcf   lubBI12.pcf    ncenR08.pcf
12x24rk.pcf    clR7x10.pcf    helvBO24.pcf   lubBI14.pcf    ncenR10.pcf
5x7.pcf        clR7x12.pcf    helvO08.pcf    lubBI18.pcf    ncenR12.pcf
5x8.pcf        clR7x14.pcf    helvO10.pcf    lubBI19.pcf    ncenR14.pcf
6x10.pcf       clR7x8.pcf     helvO12.pcf    lubBI24.pcf    ncenR18.pcf
6x12.pcf       clR8x10.pcf    helvO14.pcf    lubI08.pcf     ncenR24.pcf
6x13.pcf       clR8x12.pcf    helvO18.pcf    lubI10.pcf     nil2.pcf
6x13B.pcf      clR8x13.pcf    helvO24.pcf    lubI12.pcf     olcursor.pcf
6x9.pcf        clR8x14.pcf    helvR08.pcf    lubI14.pcf     olgl10.pcf
7x13.pcf       clR8x16.pcf    helvR10.pcf    lubI18.pcf     olgl12.pcf
7x13B.pcf      clR8x8.pcf     helvR12.pcf    lubI19.pcf     olgl14.pcf
7x14.pcf       clR9x15.pcf    helvR14.pcf    lubI24.pcf     olgl19.pcf
7x14B.pcf      courB08.pcf    helvR18.pcf    lubR08.pcf     symb08.pcf
7x14rk.pcf     courB10.pcf    helvR24.pcf    lubR10.pcf     symb10.pcf
8x13.pcf       courB12.pcf    luBIS08.pcf    lubR12.pcf     symb12.pcf
8x13B.pcf      courB14.pcf    luBIS10.pcf    lubR14.pcf     symb14.pcf
8x16.pcf       courB18.pcf    luBIS12.pcf    lubR18.pcf     symb18.pcf
8x16rk.pcf     courB24.pcf    luBIS14.pcf    lubR19.pcf     symb24.pcf
9x15.pcf       courBO08.pcf   luBIS18.pcf    lubR24.pcf     tech14.pcf
9x15B.pcf      courBO10.pcf   luBIS19.pcf    lutBS08.pcf    techB14.pcf
charI08.pcf    courBO12.pcf   luBIS24.pcf    lutBS10.pcf    term14.pcf
charI10.pcf    courBO14.pcf   luBS08.pcf     lutBS12.pcf    termB14.pcf
charI12.pcf    courBO18.pcf   luBS10.pcf     lutBS14.pcf    timB08.pcf
charI14.pcf    courBO24.pcf   luBS12.pcf     lutBS18.pcf    timB10.pcf
charI18.pcf    courO08.pcf    luBS14.pcf     lutBS19.pcf    timB12.pcf
charI24.pcf    courO10.pcf    luBS18.pcf     lutBS24.pcf    timB14.pcf
charR08.pcf    courO12.pcf    luBS19.pcf     lutRS08.pcf    timB18.pcf
charR10.pcf    courO14.pcf    luBS24.pcf     lutRS10.pcf    timB24.pcf
charR12.pcf    courO18.pcf    luIS08.pcf     lutRS12.pcf    timBI08.pcf
charR14.pcf    courO24.pcf    luIS10.pcf     lutRS14.pcf    timBI10.pcf
charR18.pcf    courR08.pcf    luIS12.pcf     lutRS18.pcf    timBI12.pcf
charR24.pcf    courR10.pcf    luIS14.pcf     lutRS19.pcf    timBI14.pcf
clB6x10.pcf    courR12.pcf    luIS18.pcf     lutRS24.pcf    timBI18.pcf
clB6x12.pcf    courR14.pcf    luIS19.pcf     ncenB08.pcf    timBI24.pcf
clB8x10.pcf    courR18.pcf    luIS24.pcf     ncenB10.pcf    timI08.pcf
clB8x12.pcf    courR24.pcf    luRS08.pcf     ncenB12.pcf    timI10.pcf
clB8x13.pcf    cursor.pcf     luRS10.pcf     ncenB14.pcf    timI12.pcf
clB8x14.pcf    deccurs.pcf    luRS12.pcf     ncenB18.pcf    timI14.pcf
clB8x16.pcf    decsess.pcf    luRS14.pcf     ncenB24.pcf    timI18.pcf
clB8x8.pcf     fonts.alias    luRS18.pcf     ncenBI08.pcf   timI24.pcf
clB9x15.pcf    fonts.dir      luRS19.pcf     ncenBI10.pcf   timR08.pcf
clI6x12.pcf    helvB08.pcf    luRS24.pcf     ncenBI12.pcf   timR10.pcf
clI8x8.pcf     helvB10.pcf    lubB08.pcf     ncenBI14.pcf   timR12.pcf
clR4x6.pcf     helvB12.pcf    lubB10.pcf     ncenBI18.pcf   timR14.pcf
clR5x10.pcf    helvB14.pcf    lubB12.pcf     ncenBI24.pcf   timR18.pcf
clR5x6.pcf     helvB18.pcf    lubB14.pcf     ncenI08.pcf    timR24.pcf
clR5x8.pcf     helvB24.pcf    lubB18.pcf     ncenI10.pcf    xhextris.pcf
clR6x10.pcf    helvBO08.pcf   lubB19.pcf     ncenI12.pcf    xmahjongg.pcf
clR6x12.pcf    helvBO10.pcf   lubB24.pcf     ncenI14.pcf
clR6x13.pcf    helvBO12.pcf   lubBI08.pcf    ncenI18.pcf

[ This directory is empty ]

    Note the "fonts.dir" and "fonts.aliases" files in the "fonts" directory. These files contain the mappings of human- readable font names to file names on the boot server. They can be generated (in the "native" X directory) on a Linux host then copied into place in the fonts/ directory. The X-station 130 loads fonts on an as- needed basis, so not all of these will be loaded at run- time.

    I am given to understand that some individuals have had difficulty in getting some of the images in the "boot" directory to load correctly, especially with code loaded from FTP sources. Here are the sizes and simple Linux checksums ("sum filename") for the key files:

bootfile4    284906 bytes  sum: 47791   279
x11xor4.out  593636 bytes  sum: 61110   580

    Please do note that the checksums above are only for the version of the X-station code that I happen to have here. Other revisions of the code will, of course, show different values.

    Once the "bootfile4" bootstrap code is loaded from the boot server, it needs to be told where the other data are found. It does this by loading and reading the "" file in the boot directory. The format is fixed concerning line order, but it's pretty straight- forward. Here's mine:


    Once all of this is done, the little 130 should be able to boot up its X-server code and put it into execution. This will be apparent when the familiar grey crosshatch screen comes up with the "X" cursor in the center of the screen.

    Once the 130 is booted the user needs a way to log into a system and start the X-client programs he desires. In the IBM world, this is typically handled by the Xstation manager daemon. In a non- IBM environment, however, that program doesn't exist and a substitute has to be found. That substitute is "xdm" - the "X Display Manager".

    XDM is capable of managing a display in either a dedicated manner or in a dynamic manner with displays (X-stations) requesting login service via broadcast messages. The X-station 130 is capable of functioning in either environment.

    In a statically configured envirionment, the XDM configuration file which specifies which displays are to be serviced gets modified. In this case the xdm's configuration file "/usr/lib/X11/xdm/Xservers" needs to be modified. The line: foreign

is what I use here. Substitute the address of your 130 in place of the one I used (it's the same as the "Terminal Internet Address" field from the setup screens on the 130.

    Xdm does not cope well with statically- configured servers which it thinks have gone off- line; this means that if you're going to power your 130 off for any appreciable period of time in such an environment you're going to have to restart the xdm process. Fortunately under UNIX this is easy and is done with a "kill -HUP" giving the PID of the xdm process as an argument. (You'll have to do this when you modify the Xservers file as well.)

    As an alternate to static configuration, it is possible to have the X- station 130 broadcast a "request for service" to systems on the local area network which are running xdm. This method makes use of the X Display Manager Control Protocol, or XDMCP. To configure the 130 to use XDM, one makes a single change on the Networking Setup screens. All that needs to be done is to set the "Tags" field in the network settings to:


    In addition to configuring the X-station to use XDMCP the file "/usr/lib/X11/xdm/Xaccess" on the desired host needs to be altered to have a line of:


    (That's right -- a single asterisk in the leftmost column) entered into it and xdm restarted. This states that a request from any X-station should be honoured and a login prompt granted.

    Once those steps are taken and the X-station rebooted, the X-station should come up with a logon screen without xdm needing to be reset again. Note that if you're on a large LAN you may get several logon services at once.

    Finally, as a third option, it is possible to allow the X-station to acquire its configuration from a BOOTP server. In this environment, the operator doesn't need to put anything in the X-station's configuration screens, but does need to make changes to a file on the LAN's BOOTP server. This section will describe how it's done.

    With BOOTP enabled on the X-station, it becomes possible to completely clear out the configuration screens, thusly:

Network Setup             Page 2


Ethernet/IEEE 802.3 ..............Automatic

Gateway Internet Address .........
Terminal Internet Address ........
Host Internet Address ............
Disable BOOTP ....................NO
   TFTP File Name ................
   Tags Field ....................


    From the first page in the setup screens, the operator must find the hardware address of the X-station and give it to the LAN administrator who must then create an entry for the X-station in the "/etc/bootptab" file. That entry, on my Linux box, looks like (without the comments):

x-station:\					# Xstation name
    :ht=ether:ha=0x000000000000:\		# Hardware Address Here
    :ip=\		# Xstation IP addr + mask
    :sa=\		# Code server and def gateway
    :hd=/var/tftp:bf=Xstation/boot/bootfile4:\	# Boot file
    :vm=rfc1084:T178=01:			# Magic - see below

    In the above example, the hardware (MAC) address gets placed into the file as a hexidecimal constant following the :ha= tag. This allows the bootp server to recognise the Xstation and give it the right information when the Xstation boots up. The last line instructs the bootp server how it should behave when a boot request comes in, and that it should pass back the "T178" tag with a value of "1" in it. This enables XDMCP so the terminal can get a login prompt.

    Note that it's really not practical, or advisable, to run in this mode and try to statically configure your login service in the Xservers file. It is possible, as you're assigning a static IP address (in /etc/bootptab) but why go to the bother. XDMCP is easier to deal with, anyway.

    I currently do DHCP and XDMCP dynamic configuration of my X-station 130. I use ISC's DHCP daemon and run XDM on a machine in my network that has connectivity to both my token-ring and Ethernet segments.

    My /etc/dhcpd.conf file entry for my X-station reads thusly:

host uillagh {
  hardware ethernet 08:00:5a:7a:18:c8;
  filename "/var/tftp/Xstation/boot/bootfile4";
  server-name "";
  always-reply-rfc1048 true;
  option host-name "";

  option xstation-mode 3;
  option xstation-mgr;

  allow bootp;
  allow booting;

    In addition to the stanza above, I have the following entries in the global portion of the file:

option xstation-mode code 178 = unsigned integer 8;
option xstation-mgr  code 179 = ip-address;

    Those entries define tags 178 and 179 to the DHCP server. Note that all the other bits associated with running a DHCP server must be in place to support the above. At an absolute minimum one will require subnet-mask, broadcast-address, and range statements.

    The "xstation-mode 3" entry specifies that the machine is to make indirect XDM requests to the node specified in the "xstation-mgr" statement. This is to say that the X-station will contact the "xstation-mgr" machine and ask to call up the XDM "chooser" program. The XDM chooser program will then display a list of machines on network segments that it can "see" that are willing to provide XDM logon sessions to clients.

    In addition to getting the X-station to boot, which the above configuration allows, one must grant it access to the various X servers and to the chooser program on the "indirect" node. To facilitate this, I have the following lines in my /usr/lib/X11/xdm/Xaccess file active:

*                             #any host can get a login window
*     CHOOSER BROADCAST       #any indirect host can get a chooser

    In addition to all of the above, the X-station is NFS-aware. This allows for enhanced access to fonts and to the paging file. To take advantage of this facility, the directory hierarchies listed in the file must be exported for NFS access to the X-station (or, more commonly, the entire LAN). Using NFS for font-file access is several times faster than using TFTP for the same function.

    The X-station 130 is also capable of using standard X11 font servers in addition to NFS and TFTP. I have had very mixed results in my testing of font-servers, and instead have settled on using NFS as the preferred access mechanism.

    Once the 130 boots it will take a few moments to load the required fonts for the login prompt, so be patient. Once things are rolling, the performance is pretty good on the 130. The one I have is more than sufficient for command shell windows, checking mail, and even simple graphics. However as mine only has 1 Mo of mainstore getting something large and complex (e.g. Netscape) running on it is asking for trouble. A typical boot takes roughly 45 seconds. Power- up from a cold start takes a while longer as the machine has to run through its POSTs before it begins the boot process.

    Good luck configuring yours!

[ Museum Lobby ] [ Museum Catalogue ] [ Carl's Homepage ]

Copyright © 1999 - 2003, Carl R. Friend. All rights reserved.
Webspace design by: Carbon & Silicon Alliance

Comments to:
Last Modified: Thu Nov 28 13:21:09 EST 2002