This document is to serve as a comprehensive HOWTO and FAQ collection regarding the Sun JavaStation NC ™ and enabling the GNU/Linux OS on it.

The intended audience of this document is anyone who has an interest in enabling Linux on the Sun JavaStations™. The document structure is laid out to serve as either a top-to-bottom read for a newcomer, or as quick reference on a single topic for advanced users. Pointers to sample files submitted by users are included for extremely hurried readers.

The author of this document is Robert Dubinski <rsd@dubinski-family.org>. Robert is the former computer technician and UNIX systems administrator for Marquette University's Math, Statistics and Computer Science Department, where he had 125 JavaStations™ running Linux. These machines were all configured using the information, techniques and files presented in this document.

In early 1999, Eric Brower <ebrower@usa.net> wrote the first informal HOWTO for the JavaStation™. Parts of this document are inspired by his work, and all unique information presented there have since been merged into this document. Eric's original mini-HOWTO is saved for posterity at: http://dubinski-family.org/~jshowto/Files/texts/eric_brower_js_howto_19980218.txt

This HOWTO also aims to serve as a member document of the Linux Documentation Project. The LDP can be reached at: http://www.linuxdoc.org

Enabling Linux on the JavaStations ™, and allowing this HOWTO to come to be would never have been possible without the fine work of the following people:

The HOWTO author wishes to give a second thank-you to Pete and Eric for their work:

The document author makes no warranties that all the information presented here is completely accurate, and cannot be held liable to any loss you experience as a result of the information you use from here.

Best efforts have been made to ensure everything included is accurate as of the publication date listed at the beginning of this document, but there is always a possibility something may be wrong. In this case, doublecheck with alternative sources first before considering implementing anything at a production-level. If you find something wrong, drop the author a line at <rsd@dubinski-family.org> or send a patch to the document source, and corrections will be made immediately.

This document is an official member document of the Linux Documentation Project.

The latest online version of this document can be found at: http://dubinski-family.org/~jshowto .

The pre-processed XML source to this document, written to the Docbook DTD, version 4.1.2, is available from: http://dubinski-family.org/~jshowto/doc/src/

The pre-processed XML source to the GNU Free Documentation License, written to the Docbook DTD, and which this document is licensed under, is available from: http://dubinski-family.org/~jshowto/doc/src/gfdl.xml

Copies of this document are also available from the Linux Documentation Project at: http://www.linuxdoc.org/HOWTO/JavaStation-HOWTO.

This project used to be available at the URL 'http://javastation-howto.homeip.net'. In Spring 2001, homeip.net discontinued their free service and moved to a fee based scheme. Given the hundreds of mirrors of LDP documents, I do not find the fees justifiable. I have changed all references in this document back to my home server. Between my server's address, http://dubinski-family.org/~jshowto, the LDP website, and its hundreds of mirrors, you should be able to always find the JavaStation-HOWTO. If this is not the case, email me immediately at either <rsd@dubinski-family.org> or <dubinski@mscs.mu.edu>.

Any problems or concerns about the HOWTO should be reported via email to the author, Robert Dubinski, at <rsd@dubinski-family.org>. Do NOT send document bug reports to the SparcLinux mailing list, the debian-sparc mailing list, or the Linux Documentation Project. The folks on there really do not care about my typos or server misconfigurations, so please don't trouble them.

The JavaStation™ NC is a model line of network computers built and sold by Sun Microsystems between November 1996 and March 2000. The JavaStation™ line was Sun's low-cost terminal option during that timeframe. It was the marketed successor to the Xterminal 1 and is succeeeded by the SunRay, although all three machines are fundamentally different.

The JavaStation™ hardware ran Sun's own JavaOS and either Sun's Hotjava web browser, Sun's HotJava Views task-manager software, or custom Java applications of the customer's choice.

The JavaStation™ was originally billed in November 1996 sneak previews as a low-cost desktop terminal, providing customers access to hot new Java applications, “legacy” X applications, and “legacy” MS Windows apps. During its lifetime, The JavaStation™'s marketed functionality was changed twice from “desktop terminal” to “single-app desktop device” to finally a “browser-based kiosk device”.

At no time did Sun market the JavaStation™ as capable of running its flagship Solaris operating system the Linux OS, or any other OS than Sun's JavaOS.

A network computer, or NC, was hailed as "the next big thing" in computing from late 1995 to early 1998. Conventional PC's, called "fat clients", were expected to be minimized in businesses by thin-client NC's.

Thin-clients get their OS, applications, and data files entirely through the network. They are different from dumb-terminals; they run full-scale graphical applications. Thin-clients are also different than graphical X-terminals. X-terminals typically run an X server and display the client programs of a remote server. Thin clients generally run full-scale graphical programs locally, such as a web browser, a Java application, or a “legacy-connectivity program”, which enables the thin-client to display X apps or MS Windows apps which run on more powerful servers.

Advantages of NC's include:

Disadvantages of NC's:

Depending on who you talk to, the number of JavaStation ™ models that were created is anywhere from one to six. The descriptions below will explain why.

Boot device: /ethernet   Arguments:
MAC Address: 08:00:20:95:5b:49
Open Boot 3.0, Built February 16, 1999 17:38:37
NIC: 10b7,9055 ethernet in PCI1                                           64MB SDRAM
Non-Volatile Device Memory Module Not Installed
SmartCard Reader Found
CPU Speed:  266 MHz


Can't open boot device

ok                         

It turns out that Linux makes the JavaStations™ perform more than adequately on the desktop. Thanks to the dedicated work of the Linux developer community, the JavaStations™ offer users the low-cost, zero-admin, versatile desktop NC's they were originally billed to be, but with the added freedom granted by the Linux OS.

While low-cost PC's now eclipse the JavaStation ™ in terms of default CPU speed and RAM size, the JavaStations™ running Linux are still well-suited for a number of tasks:

In all of the above scenarios, there is little to no maintenance of the machine once configured properly. Such is the advantage of the NC hardware.

JavaStations™ run so much better with Linux than JavaOS, one would think that even Sun should have offered it as an option. Unfortunately, Sun had killed the line in favor of the Sun Ray ™. While the performance of the Sun Ray ™ is good, keep in mind it is not intended as a dedicated computing device, and due to its firmware is little more than a graphics display hanging off your Sun server, which can give you some unexpected bonus features (translation: “brand-name product lock”). The performance on the JavaStations™ with Linux will be similar to what you can get with a Sun Ray™, but if ever you want to do something different with your machines, you have the flexibility to do so with the JavaStations™. There was rumor of work to try and override the default behavior of the SunRay firmware, and make it into an adjustable computing device, but until that happens, running another OS on a SunRay is just a pipe-dream.

Lastly, if you're thinking of switching to diskless Xterminals on your network, you might consider the JavaStations ™ over stripped down PC's. The hardware is standardized, smaller, and you do not need to worry about burning boot PROMs and the like.

Sun's official stance is that the JavaStation™ line was terminated in favor of the new Sun Ray™ line. A trip to the former JavaStation™ section of Sun's website at http://www.sun.com/javastation verifies this formal positioning. (fair use archival copy at: http://dubinski-family.org/~jshowto/Files/texts/sun_js_site_death.txt )

As the Sun Ray™ is not an NC in the traditional sense (it has a MicroSparc IIep CPU, but the firmware on the device prevents anyone from grasping it), there is no explanation why the two products could not co-exist.

In talking to the users of the JavaStations™ in the pre-Linux era, you will find strong opinions as to why the JavaStations™ are no more. The common thread in almost all opinions collected is that the software provided by Sun was inadequete for a production environment. Here are collected opinions from users of the Sun-provided software, included with their permission:

More comments and rebuttal statements by Sun employees are always welcome.

(update Oct 2001): A year and a half of this document's existance and not a single rebuttal statement by Sun. There were a couple initial requests to omit this section, but I refused. After all, imagine a new reader who never saw a JavaStation before: They'd read to this section, think "Wow, what a great little machine..let me get one!", and then ask themselves, "If it did all this, why don't they make them anymore?". The bad must be included with the good, and to leave this section out is a disservice to all the users who suffered through the poor software and support during the official lifetime of the JavaStation. This section, therefore, is a necessity, and although this document is licensed under the GNU Free Documentation License, the eagle-eyed reader will note that this section has been labeled as "invariant" to protect it from entities who may wish to bury it (which is precisely the reason why the Invariant clause of the GFDL exists).

Since Sun has canceled production of the JavaStation™ line, it no longer sells them through their official channels. Sun contacts have informed me that all internal JavaStation stock was cleaned out and dumped in 2000. Therefore, All JavaStations are now found out in the wild.

Your best bet to get JavaStations™ though is out on the open market. Educational institutions which received a handful from Sun as demo units are now trying to offload them any way they can (too bad they don't read this HOWTO). Search around the auction sites like Ebay and Yahoo Auctions, and you should be able to turn some up.

A great resource for JavaStations™ used to be “Bodoman's JavaStation site” at: http://www.bodoman.com/javastation/javastation.html. Sadly, as of October 2001, the domain bodoman.com seems to no longer resolve. Ebay may now be your best bet.

Mr. Coffee is the most widespread JavaStation model, and has tended to sell around $30-80US consistently for the last year or so.

Krups models more rare and sell at higher prices, probably because the stylish case still stands out today. Prices on Ebay are always over $100, but for Oct. 2001, their technology is definitely no longer worth that much. A good price would be $80-85US. Many reports have come from the UK telling of many Krups models getting dumped there.

The Dover models were a very hush-hush thing when this HOWTO was initially published, but the secret is out: if you want one, go to South Africa. Dovers seemed to have been dumped there en masse. Pricing is unknown, but should be comparable to a Cyrix-266 PC clone.

The Espresso and JavaEngine models are near impossible to find, so if you get one, consider yourself lucky. If you have a Fox, well, you're just too cool. Pricing for these models is likely a premium. (>$100US).

For hardware, you will need one or more JavaStation™ clients and a server to feed it its Linux image from, all networked on the same net segment.

This server you use can be any server which supports DHCP and TFTP, and RARP. These are the base protocols needed to perform a network boot of the JavaStations™. You may also need NFS service as well, but it is not necessary in one type of configuration this HOWTO describes. Also, you can get by without RARP on both the Krups™ and Espresso ™ models.

This document will describe how to set up serving the network Linux OS image to the JavaStation™ from a Sun server running SparcLinux. While you do not need a Sun server to serve your Linux image off of, a Sun SparcLinux server is recommended should you wish to compile a kernel of your own, or prototype a new filesystem for your JavaStations™ to use. Otherwise, you will need to use prepackaged kernels and filesystems somebody else has pre-built and made publicly available for use. (You might also use a cross-compiler to produce the kernel images, but prototyping a filesystem is best done on a Sun SparcLinux server.)

Reports of successful boot servers used include Sun boxes running Sparclinux, Sun boxes running Solaris, and PCs running MS Windows. It is only when you are building a new kernel or filesystem that a Sun box running Linux becomes valuable.

Your network can be a simple 10 Mbps ethernet LAN, but when you begin using more than 50 JavaStations™ at once, a switched 100 Mbps network becomes desirable for your server to handle multiple concurrent boot requests.

This HOWTO includes pointers to example kernels, filesystems and a complete out-of-the-box solution for you to use, eliminating your need for a Linux/SPARC server, but you still need a server of some type to feed the image to the JavaStations as they boot.

As discussed in the last section, the JavaStation™ boot cycle will make use of DHCP and TFTP with possibly NFS and RARP. To understand why, read up on the JavaStation™ boot sequence in the next section.

The JavaStations™ follow a typical diskless workstation boot sequence.

When powered on, the JavaStation™ sends out a broadcast request for its IP. It gets its IP info via RARP or DHCP. With a DHCP response, it gets information about the network it is on and where to go download its boot image from via TFTP.

There are subtle variations in diskless boots from one diskless machine to the next. For instance, BOOTP may sometimes be substituted where DHCP is, and RARP may be eliminated in favor of either of the two. But in general, the sequence is typically the same between the client and the server:

After the kernel is finished loading, your diskless client typically mounts its root filesystem from the network via NFS. Alternatively, it may load and mount it from a RAMdisk.

The original JavaOS and Hotjava Views environment, when run on a JavaStation, required the setup and maintenance of the core services above, plus also NIS, HTTP, DNS, POP, and NTP servers. If setting up a JavaStation boot server seems like a lot of work, imagine adding these extra services into the mix too.

JavaStations™ came with two different PROMs installed in them. Version 2.30 shipped with the earliest Mr. Coffee™ models, and was updated by latter versions of the Sun Netra J software environment to 3.11. Krups™ and Espresso™ came with 3.x versions of the PROM by default.

It turns out the later 3.x series of PROMs is not conducive to booting Linux upon. Fortunately, a complete PROM replacement called PROLL now exists to get by this limitation.

PROLL becomes the first image your JavaStation™ grabs by TFTP. It then will load your true kernel image and boot into Linux .

No matter what PROM revision you have, get PROLL. This can make troubleshooting new installs easier.

The current, master version of PROLL is available from: http://people.redhat.com/zaitcev/linux/.

The current version at the time of this writing is “14”.

PROLL can also be found mirrored on “VGER ”, and also on this HOWTO's distribution site at: http://dubinski-family.org/~jshowto/Files/proll/proll_14.tar.bz2 (HOWTO website mirror - version 14)

Before you begin, you must decide upon the root-filesystem type you wish to use for your diskless JavaStation™. There are two possibilities.

One website to keep on reference when you begin thinking about putting Linux on your JavaStation is kernel hacker Pete Zaitcev's website at: http://people.redhat.com/zaitcev/linux/, referenced throughout this document as the “ZLS” site (short for "Zaitcev's Linux Site"). Here you will find the latest version of PROLL and many low-level details about dealing with the JavaStations. Many items on the ZLS have been merged into this document, but not all.

Oct. 2001 update: It is in your best interest to review all the information on Pete's site, in this document, and references pointed to, before diving in and setting up your JavaStation with Linux. Almost all questions people have had in setting up their systems are covered in the materials presented.

This chapter assumes you wish to compile your own Linux kernel for the JavaStation™. If this is something you can not do, there are sample kernels pointed to at the end of this chapter.

This chapter assumes you already know how to compile Linux kernels in general, perhaps on a PC, a SPARC server running Linux, or any of the other Linux ports. If not, read the Kernel-HOWTO and the README file of your kernel source.

Compiling a kernel for a JavaStation™ is not much different than compiling a Linux kernel elsewhere. You just need to know the right options to pick. In general, you're compiling for a Sun4M class architecture, and enabling JavaStation™-specific options. The following sections in this chapter will take you through the steps.

While it may be possible to compile the JavaStation™ -enabled kernel on alternate platforms by way of a cross-compiler, this HOWTO assumes you will do it on a Linux/Sparc based server running in 32-bit mode. Cross-compiling will not be covered, and questions regarding it will not be entertained.

When compiling your own JavaStation™-capable kernel on a Sun server, you need to make sure the machine you work on is set to 32-bit mode. So, if you're on an Ultra-class machine, be sure to first switch to 32-bit mode before you begin compiling.

To check what mode you're in, do a uname -a. If it says “sparc”, you're in 32-bit mode and don't have to do anything. If it reports “sparc64”, then you should perform a sparc32 bash first to switch to 32-bit mode. A subsequent uname -a should reflect the change.

The kernel source revision you should use depends both on which model of JavaStation™ you have, and which series kernel you are using. The current "stable" series of Linux kernels is 2.4.x, but as we will read in a minute, this may not be the best bet to use.

First, a few note on the 2.2.x and 2.3.x series. Mr. Coffee™ has had kernel support since about kernel version 2.2.5, and definitely works out of the box with the RedHat 6.0+/SPARC distribution kernels. Krups™ support did not work well out of the box until the latter 2.3.x kernel cycle. Krups support was added in the early 2.3.x sequence, but the MMU changes to the 32-bit SPARC kernel had kept it from compiling cleanly until later on.

Kernels for both Mr. Coffee and Krups compiled cleanly by the HOWTO author with the Mar. 17, 2000 CVS kernel, and are included in the Sample Kernels section.. Krups™ support was backported into the 2.2.x kernels (where x>15). The latest 2.2.x kernel "should" compile cleanly for the Mr. Coffee and Krups models, but your mileage may vary.

Now onto the 2.4.x series.

The only kernel which has been tested and compiles cleanly for Mr. Coffee and Krups is version 2.4.2. All other versions are broken or require a patch.

The reason for this is that the sparc32 branch of the kernel has not had an active maintainer for many months. Some are contributing fixes, but without an active maintainer things go slow.

There is another reason to be weary of the 2.4.x series. From 2.4.0 through 2.4.9, the VM of the kernel was found to be inadequate under heavy loads, and was subsequently replaced in 2.4.10+. This was a big change for the so-called "stable" series of kernels.

To add further insult to injury, there have been security flaws detected in all of 2.2.x kernel series and up through 2.4.12. This is patched in pre-2.2.20 and 2.4.12+. As of this writing, 2.4.12+ has not been checked by the author as functioning on the JavaStations.

So basically, it has been a crap-shoot over which kernel to choose. Try a few until you find one that suits you best.

If you can not get a kernel to compile, or wish to avoid the headache or trying, you may try the samples pointed to by this document.

When you do your make config command to enter the kernel configuration stage, there are a few things you are required to enable. Note that the following option names are from a 2.2.x kernel, and may be slightly different on a 2.4.x series kernel. If in doubt, check the sample files later in the chapter.

For all JavaStations™, you want to enable PCI support:

CONFIG_PCI=y 

Don't forget your mouse:

CONFIG_BUSMOUSE=y 
CONFIG_SUN_MOUSE=y 

You'll want video, done with the Linux framebuffer interface:

CONFIG_FB_TCX=y (for Mr. Coffee) 
CONFIG_FB_PCI=y 
CONFIG_FB_IGA=y (for Krups/Espresso) 

Audio is done with the Crystal Audio 4231 chipset:

CONFIG_SPARCAUDIO=y 
CONFIG_SPARCAUDIO_CS4231=y 

Don't forget your network interface:

CONFIG_SUNLANCE=y (Mr. Coffee) 
CONFIG_HAPPYMEAL=y (Krups/Espresso) 

You'll no doubt need to support a filesystem:

CONFIG_EXT2_FS=y 

You'll want IP autoconfiguration, and RARP/BOOTP support:

CONFIG_IP_PNP=y 
CONFIG_IP_PNP_BOOTP=y 
CONFIG_IP_PNP_RARP=y 

When doing the “NFS-Root” filesystem configuration, you will need both NFS and NFS-Root support:

CONFIG_NFS_FS=y 
CONFIG_ROOT_NFS=y 

When doing the “Embedded-Root” filesystem, configure both RAM disks and “initial ramdisk” support:

CONFIG_BLK_DEV_RAM=y 
CONFIG_BLK_DEV_INITRD=y   (for 2.4.x, also configure size of ramdisk)

You can get a working “.config” file which has the required options set later in this chapter.

If you have decided to go with the “Embedded-Root” filesystem option, you will want to make a patch to the RAMdisk driver source first.

The default size of a RAM disk when using the RAM disk driver is 4 MB. Chances are that you will want an embedded filesystem of more than that size, particularly when you start thinking about running an X server, or including a Java runtime.

You can do this for 2.2.x kernels by a manual edit yourself, or by using the patch pointed to below. The change is a one-line edit in the file <LINUXROOT>/drivers/block/rd.c . Look for a line that says:

int rd_size = 4096; /* Size of the RAM disks */ 

and change it to the size of the RAMdisk you wish. Typically, most embedded systems are under 16 MB, so a common edit is to change the line to:

int rd_size = 4 * 4096; /* Size of the RAM disks */ 

If you can not do this, the patch below makes the edit for you.

4MB to 16MB kernel patch file is at: http://dubinski-family.org/~jshowto/Files/patches/ramdisk_patch.txt

Kernels in the 2.4.x series allow you to select the amount of RAM as a configuration option. The patch is no longer needed for those kernels.

It should also be noted in this section that there is currently a limit on the size of Linux boot image for all JavaStation™ models, due to the implementation of PROLL. This limit is technically 8 MB. This topic is mentioned again in the “Questions and TroubleShooting” section of this document.

To build the kernel, you type make vmlinux. If you come from an x86 Linux background, you might be surprised that you do not perform a make bzImage or make zImage. Do not be alarmed: this command is correct.

When the compile is finished, you will find a file named “vmlinux ” in the kernel source root directory. You are almost ready to put this kernel to use.

You need to make one more change to your kernel before it is ready for use. You need to convert it from ELF to AOUT executable format. You can do this with the “elftoaout ” utility included in most Linux/SPARC distributions.

To convert your kernel image to the AOUT executable format, you issue the command:

elftoaout -o vmlinux.aout vmlinux 

You will probably now want to rename the image file to a longer name which includes the current date and kernel revision you used, so as not to get confused with when you have multiple boot kernel images down the road.

The elftoaout program should come with your SparcLinux distribution. If not, try VGER or your favorite kernel mirror.

Here are some sample “.config” and JavaStation ™-ready kernel images. They were prepared and donated to help get you up-to-speed quickly.

Warning: Some of these kernel images are considered out of date, and should be avoided in a production environment. It is up to you to decide how much of a liability you feel running them holds. The document author and kernel contributors cannot be held liable for any damage caused by the use of these kernels. They are provided with absolutely no warranties.

If for some reason you have troubles downloading, try holding left-shift on your browser as you click the link. Kernel images are compressed with bzip2 compression. They must be uncompressed before use. Kernel images are already converted to a.out format.

If you mirror these files, or can verify they work on a machine not yet confirmed, PLEASE email me so I can add your information here.

Building a filesystem for use with the JavaStations ™ is a time-consuming, but rewarding task for those who undertake it. You will learn more about library dependencies than you ever thought you could, all the time while trying to keep the overall image size as small as possible.

WARNING: This is not an easy task. Creating a lasting filesystem is not for novices. If you seriously consider undertaking this step, prepare to budget a bit of time to get things just right, particularly if you plan to make an embedded-root filesystem which fits in the 8MB limit. You have now been properly warned.

There are two common approaches one can take when rolling a new JavaStation™-ready filesystem.

Which path you take, of course, is entirely up to you. The “rescue disk” build procedure seems to work best though, as more base commands in a rescue disk are statically linked, increasing the starting image size but causing less initial library headaches. Commands included on a rescue disk also happen to be bare-bones, with many extraneous options not compiled in.

Obviously when building a filesystem in the context of the JavaStation™, you will be basing off of an existing Linux/SPARC filesystem. The filesystems that come with the RedHat, SuSE or Debian distributions are good starting points.

The configuration lines placed into “/etc/fstab” depend on whether you will be using the “NFS-Root” or “Embedded-Root” filesystem configuration.

###
#
your.nfs.server:/path/to/filesystem  /  nfs defaults,rsize=8192,wsize=8192 1 1
#
none                    /proc                   proc    defaults        0 0
###

###
#
/dev/ram /     ext2  defaults
#
/proc    /proc    proc  defaults
###

Prepping up the “Embedded-Root” boot image requires a number of extra steps. Due to these extra steps, the “NFS-Root” filesystem option is recommended for beginners to Linux on the JavaStation™. You might also try the samples pointed to in this document. Should you still wish to build and embedded image on your own, this section outlines the basic instructions.

Creating the “Embedded-Root” boot image is a 5-Step Procedure:

Congratulations! You've created an “Embedded-Root” kernel/filesystem boot image.

Here are some sample filesystems for you to start with. They have been contributed by various JavaStation users.

Warning: Some of these filesystem images may be considered out of date, and should be avoided in a production environment. It is up to you to decide how much of a liability you feel running them holds. The document author and filesystem contributors cannot be held liable for any damage caused by the use of these files. They are provided with absolutely no warranties.

One of the most frequently asked questions users have is where to get an X server from. Here are some sample X servers for you to start with. They have been contributed by various JavaStation users.

Warning: Some of these files may be considered out of date, and should be avoided in a production environment. It is up to you to decide how much of a liability you feel running them holds. The document author and filesystem contributors cannot be held liable for any damage caused by the use of these files. They are provided with absolutely no warranties.

Of course, other filesystems and tools exist outside this document, and have been used by JavaStation users. Here are a few files that were reported on the sparclinux mailing list as having been used.

This is simple solution #1, or at least it will be when it gets created. Right now this section is a stub for the future files.

It is now time to setup your server to deliver the OS and filesystem to the JavaStation™.

In our examples here, we configure a Linux/SPARC server “lnxserv ” at private IP 192.168.128.100 to deliver a boot image to JavaStation™ “java01” at private IP 192.168.128.1. Both are on private network 192.168.128/24. When using an “NFS-Root” Filesystem, the location on the server of the filesystem in our sample is at “/path/to/nfsroot ”.

We first need to set up RARP service on our server, so the JavaStation™ can auto-configure its IP.

First, populate the “/etc/ethers” file with the mapping of the mac address of the JavaStation™ to its hostname:

### /etc/ethers 
8:0:20:82:7a:21  lnxserv  # 192.168.128.100 (server is not necessary,)
#                         #                 (just for completeness)
#
#
08:00:20:81:C2:ae java01   # 192.168.128.1 (JavaStation)
#
###

Next, populate the “/etc/hosts” file with the IP to hostname maps:

### /etc/hosts 
192.168.128.100 lnxserv
192.168.128.1 java01
###

Lastly, configure the RARP cache to fill. On 2.2.x based systems, you do this with the /sbin/rarp command, so fill the cache at startup:

### Part of rc.local
#
# If necessary, first load the rarp module to be able to fill the cache.
# /sbin/insmod rarp
#
# Now we fill the rarp cache.  You better have the rarp command available.
if [ -f /sbin/rarp ]; then
        /sbin/rarp -f
fi
###

On 2.4.x based systems, you must use the userland RARP daemon to answer RARP requests instead.

You now need to configure your server to deliver DHCP service. This will help identify the JavaStation™, the network it is on, and where to get its boot image from.

The following is a sample “dhcpd.conf” file for the ISC DHCP server software which ships with most Linux/SPARC distributions.

### Sample /etc/dhcpd.conf file for ISC DHCPD
#
deny unknown-clients;
#
subnet 192.168.128.0 netmask 255.255.255.0 
{
   range 192.168.128.1 192.168.128.150;
}

group 
{
   host java01 
   {
      hardware ethernet 08:00:20:81:C2:ae;
      filename "C0A88003";        # "/tftpboot/xxx"
      fixed-address java01;       # 192.168.128.1
   }
}
#
### End dhcpd.conf file

A longer dhcpd.conf from the ZLS is mirrored here for demonstration purposes.

Note: Some early versions of ISC DHCPD are reported to not work well. It is recommended you use ISC DHCPD Version 2.0 and above. If you still find youself having problems, there is a patch to the ISC DHCP server on the ZLS website.

When you are serving up an “NFS-Root” filesystem, you need to share the filesystem you created to the JavaStation ™ client. You do this with the “/etc/exports” file.

###/etc/exports
/path/to/nfsroot        java01(rw,no_root_squash)
###

Be sure your NFS server gets properly started up at boot-time.

Now we need to set up the last step on our server: the TFTP configuration. For this step, you will need the kernel you created (using the “NFS-Root” option) or the piggybacked kernel/fs boot image (using the “Embedded-Root” option), the appropriate PROLL, and some knowledge of hexadecimal numbering.

The first thing you need to do is verify that “TFTPd” is enabled in your “/etc/inetd.conf” file:

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

Now, you move your copy of proll for your JavaStation ™ architecture, along your kernel or piggybacked kernel image to /tftpboot.

Now, you create of symbolic link from the hexidecimal version of your IP to your PROLL image, and a map from “HEXIP.PROL” to your real kernel image. If you are using “Embedded-Root” option, you point to your “Embedded-Root” Filesystem plus Kernel image. If you are using the “NFS-Root” option, you need to point to the normal “vmlinux.aout” image, plus have a separate map of IP->nfsroot location. For sake of completeness, you might also want a “HEXIP.SUN4M” -> “HEXIP ” map, as that is the custom way of dealing with net boot situations with the Sun.

Example for java01 booting from “NFS-Root”:

  $ ls -ld /tftpboot
  -rw-r--r--   1 root     root        89608 Mar 20 10:15 proll.aout.krups.11
  -rw-r--r--   1 root     root        52732 Mar 17 11:52 proll.aout.mrcoffee.11
  lrwxrwxrwx   1 root     root           19 Mar 20 10:16 proll.krups -> proll.aout.krups.11
  lrwxrwxrwx   1 root     root           22 Mar 17 11:54 proll.mrcoffee -> proll.aout.mrcoffee.11
  lrwxrwxrwx   1 root     root           10 Apr  1 13:00 C0A88001.SUN4M -> COA88001
  lrwxrwxrwx   1 root     root           10 Apr  1 13:00 C0A88001 -> proll.mrcoffee
  lrwxrwxrwx   1 root     root           12 Apr  1 13:00 C0A88001.PROL -> vmlinux.aout
  -rw-r--r--   1 root     root      1456189 May 21 12:53 vmlinux.aout
  -rw-r--r--   1 root     root      6743821 Apr  1 12:53 vmlinux_embed.aout
  lrwxrwxrwx   1 root     root           18 Apr  1 12:53 192.168.128.1 -> /path/to/nfsroot

Example for java01 booting from “Embedded-Root” boot image:

  $ ls -ld /tftpboot
  -rw-r--r--   1 root     root        89608 Mar 20 10:15 proll.aout.krups.11
  -rw-r--r--   1 root     root        52732 Mar 17 11:52 proll.aout.mrcoffee.11
  lrwxrwxrwx   1 root     root           19 Mar 20 10:16 proll.krups -> proll.aout.krups.11
  lrwxrwxrwx   1 root     root           22 Mar 17 11:54 proll.mrcoffee -> proll.aout.mrcoffee.11
  lrwxrwxrwx   1 root     root           10 Apr  1 13:00 C0A88001.SUN4M -> COA88001
  lrwxrwxrwx   1 root     root           10 Apr  1 13:00 C0A88001 -> proll.mrcoffee
  lrwxrwxrwx   1 root     root           12 Apr  1 13:00 C0A88001.PROL -> vmlinux_embed.aout
  -rw-r--r--   1 root     root      1456189 May 21 12:53 vmlinux.aout
  -rw-r--r--   1 root     root      6743821 Apr  1 12:53 vmlinux_embed.aout

There are multiple stages to the JavaStation boot cycle. What you see on screen can give you clues as to whether things are going well or not. Therefore, it is vital you become familiar with these boot stages, so you can troubleshoot problems rapidly.

On systems that have the older OpenBoot version 2.3, and are not set up to use PROLL, you will get this message when attempting to boot up a kernel image that is not in AOUT format. Be sure to run elftoaout on your kernel image, as described in the "Kernel Build" chapter.

On systems that are set up to use PROLL, you will see this message when attempting to boot up a kernel image that is not in AOUT format. Be sure to run elftoaout on your kernel image, as described in the "Kernel Build" chapter.

This likely means you have a flash SIMM install, and the flash SIMM has JavaOS loaded on it. Remove the SIMM and the problem should go away.

There is a known limit of 8 MB when using the “Embedded-Root” boot image option.

The cause of this is the current version of the PROLL software, which map only 8 MB of low memory. Any more and banking support would need to be added to it.

If needed, this limit can be fixed by someone, as the source to PROLL has been released under terms of the General Public License (GPL).

So in reality, the embedded image size limit is really 8 MB , not 10 MB. If 10 MB somehow works for you, it is sheerly by “luck”!

There are a few possibilities for this. Among them:

If you do X sessions to a Solaris server, and you find that your sessions are no longer opening up new windows, chances are the font server on the Solaris host has crashed. This is a known bug in Solaris 2.6 and 2.7 when you have about 2 dozen X terminals sessions running.

The fix is to move the font server to a different OS and point your JavaStations™ there, or to upgrade your Solaris to the 2.7 11/99 maintenance release or Solaris 8 which both (apparently) have fixes to this problem.

Congratulations! You probably have one of patch numbers 107180-12 through 107180-19 installed on a Solaris 7 server. You need to upgrade to 107180-20 or above to fix this problem.

I (your HOWTO author) reported this problem to Sun in November 1999, at which time I was told a fix was not scheduled to be made, since I was using an “unsupported configuration.”. Never mind that the client was a piece of hardware made by Sun itself. Also never mind that indirect XDMCP queries is a standard itself which was broken by Sun. A call back in late January 2000, and I learn that the record of my previous call was non-existant, but a fix was now on its way. The fix finally was made available in April 2000, five months after first reporting the problem. Considering revisions to this patch during the broken XDMCP period dealt with fixing system security issues, we were forced to run the older insecure software for five months while waiting for a fix to a problem which should have been patched immediately.

The moral of the story: test your JavaStation™ configuration against an upgraded server that is not in production mode.

If you have XDMCP problems not related to these faulty Solaris patches, it may be a new problem, so please report it.

This was reported by a user after this document was first released.

In SUSE 6.3, using the tftpd from the 'a' package of the netkit rpm, you must be sure your tftpd line in /etc/inetd.conf has the -s flag. Otherwise you need to specify a full path.

Also, it is not necessary to run tftpd as root, so the suggested username and group for tftpd on SUSE 6.3 is 'nobody' and 'nogroup'

It is not known whether these changes are needed for newer versions of SUSE.

RARP is not needed with the Krups ™ or Espresso™ models and recent PROLL software. RARP is required for Mr. Coffee™, however.

This 'Server Configuration' chapter explained how to set up kernel-level RARP on 2.2.x systems.

On servers with kernel versions 2.3.x/2.4.x, kernel-level RARP support is removed. The ZLS holds a version of ANK userland RARP from Andi Klein of SuSE that will work with Linux/SPARC. It is available from: http://people.redhat.com/zaitcev/linux/rarpd-ap1.tar.bz2. The command to use then is rarpd-ank -e eth0. “-e” makes it ignore /tftpboot checking, and “eth0” is needed if you are behind a firewall.

This is not currently supported, but the reader follows an ISO standard (ISO 7816-3). On Espresso™, if you look into PROLL, there are definitions for the GPIO smartcard data/clock in “eeprom.c”. So a programmer should technically be able to get the Smart Card slot running.

Whether the smartcard reader on Dover and Espresso are equivalent is not known.

Yes, this is possible. Earlier ISC daemons had problems dealing with 1514-byte requests of the JavaStations, while the Solaris server was able to handle them without problems. Also, former users of JavaOS may already have their Solaris DHCP server active, and wish to keep things on one machine.

Here is how to configure it:

First, fill in your /var/dhcp/“networks” file, populating it with ethernet to IP info, and the appropriate leastime.

# This example uses "infinite" leastime
#
0108002081C2AE 03 192.168.128.1  192.168.128.100 -1 java01  # JavaStation
010800208E4CF6 03 192.168.128.2  192.168.128.100 -1 java02  # JavaStation

Next, fill in your /var/dhcp/dhcptab file with entries similar to:

##
# First, some network info
#
Locale   m  :UTCoffst=21600:
www  m  :Include=Locale:Timeserv=192.168.128.100:DNSdmain=my.own.net:DNSserv=192.168.128.100:
192.168.128.0  m  :Broadcst=192.168.128.255:Subnet=255.255.255.0:MTU=1500:BootSrvA=192.168.128.100:Router=192.168.128.101:NISdmain=my.own.net:NISservs=192.168.128.100:
#
#  note: BootServA can point to a different TFTP server to get the kernel image
#        off of.
#
#
##
# Now we define the JavaStation TFTPboot parameters
#
SUNW.Linux m :Include=www:JOSchksm=0x155dbf97:Rootpath=/tftpboot:BootFile=proll.mrcoffee:BootSrvA=192.168.128.100:TFTPsrvN=lnxserv:
SUNW.Linux.Krups m :Include=www:Rootpath=/tftpboot:BootFile=proll.krups:BootSrvA=192.168.128.100:TFTPsrvN=lnxserv:
#
#
#  note: different classes are defined for the different PROLL images.
#
##
# Lastly, we list our hosts and which boot class each one gets.
java01  m  :LeaseTim=-1:Include=SUNW.Linux:
java02  m  :LeaseTim=-1:Include=SUNW.Linux.Krups:
#
#
#
###

PROLL ships with DHCP options disabled, but it could be changed. You would then do something like “/tftpboot/0A0A0000.ARGS” to get those parameters in.

If you boot from flash memory, PROLL picks up SILO options (where SILO is > version 0.9.6 and PROLL is >= version 11)

This is a very frequently asked question.

Enabling X on the JavaStation ™ is possible.

First, be sure you have enabled the appropriate framebuffer device in your kernel's configuration, as described in the "Kernel Build" chapter.

Next, you'll want to use the generic Sun Framebuffer X server and “XF86Config” file. You can build this yourself, or you can try someone's prebuilt binaries, such as the samples pointed to in the "FileSystem Build" chapter.

Recent editions of the framebuffer server coinciding with XFree 4 are reported not to work. Use the older version based on XFree 3.3, or fix the new version and be a hero to thousands.

There are two mailing devoted exclusively to running Linux on SPARC processor based machines such as the JavaStations™.

The first mailing list is the sparclinux list on VGER, at <sparclinux@vger.kernel.org>. You should first subscribe to it by sending a message to <majordomo@vger.kernel.org> with a subject and body line of “subscribe sparclinux <your_email_address>”. You can leave out your email address, but it is helpful to put it in if you have multiple valid addresses at your site.

Archives of the VGER sparclinux mailing list are kept at: http://www.progressive-comp.com/Lists/?l=linux-sparc&r=1&w=2"

The second mailing list is the debian-sparc list at the Debian Project, at <debian-sparc@lists.debian.org>. You should first subscribe to it by sending a message to <debian-sparc-request@lists.debian.org> with a subject and body line of “subscribe <your_email_address>”. You can leave out your email address, but it is helpful to put it in if you have multiple valid addresses at your site.

As many of the SPARC kernel hackers run Debian, it is helpful to subscribe to both lists.

Please do not report problems about this document to either list, but send them to <rsd@dubinski-family.org> instead. Also, please use the list archives. JavaStations have been supported on Linux for a while now, and chances are any questions you have not answered by this document are answered in the archives.

It is possible to boot a JavaStation-NC from flash, but requires too much arcane knowledge at the moment to be recommended. One problem even if you do go this route is that flash can only be mounted read-only. This gets to be a problem with many things, like X, which require the writing of socket files. A hybrid ramdisk/flash solution would be required.

With the great embedded-root solution for the JavaStations, the question popped up whether something similar can be done for stock x86 hardware. While there are some x86 NICs that have boot roms on them, you'd also need the piggyback program to put things together. According to Eric Brower, this currently is not possible as the piggyback program looks for a header specific to the SPARC platform. (28-Apr-2000)

Robert Thornburrow<robert@tsac.fsnet.co.uk> sent a version of piggyback which runs on non-SPARCLinux architectures like Linux/x86 and Solaris. This automates the task of creating your embedded root image. You can get his updated piggyback package at: http://dubinski-family.org/~jshowto/Files/tools/piggyback_nonsparc.tar.gz

Are you using EDO memory by chance? Mr. Coffee uses fast-page memory only, not EDO.

JavaStation support is now available with the NetBSD OS as well as Linux.

As of this date (Oct 31, 2001), the current stable Linux kernel version is 2.4.13. Kernels in the stable 2.4 series should work with the JavaStations, but there are a few reasons why they may not work for you. For details, check the "Kernel Build" chapter's entry on supported kernels.

It should be technically possible to compile your kernel on a non Sun workstation, such as a PC. Currently there are no reports of anyone doing this, but if you wanted, the first place to look is the GCC CrossCompiling HOWTO.

Of course, you can also compile a new kernel on a working JavaStation, if your filesystem image supports it.

A curious thing happens when you send a JavaStation a break: it resets, not break down to the openboot prom prompt like other Sun equipment. This can be changed on a Krups by setting jumper J1300, pins 7-8. Doing this gets a OBP ok prompt with a Ctrl-Alt-Break on a PS/2 keyboard or break through a serial terminal.

You can also get the ok prompt on the Dover unit, but it requires a hardware fix. To do so on this unit, you must solder a 220K ohm resistor in location R362 (near the FDD connector).

While it's unlikely, it could be possible that you have a javastation set in the wrong input device mode. To rectify this, you need to enable the openboot prom prompt as described elsewhere in this HOWTO, and then set the 'input-device' directive accordingly. Or, as one contributor did before the OBP setting was discovered, load up NetBSD on your JavaStation and run the eeprom command there. Convoluted, but it works too.

This has been reported to happen when the file PROLL looks for isn't available. Doublecheck your configuration before retrying.

Truecolor on Krups with Linux is a bit of a controversy. Some believe it is possible, while others do not.

First, the Krups is listed as having the IGS C1682 framebuffer, while the Espresso has the IGS C2000 chip.

According to an earlier report by one kernel hacker, the reason for Krups not supporting TrueColor is due to lack of kernel support for the Cyber2000 chip. Perhaps the C2000 for the Espresso is the 'Cyber2000'? And perhaps the C2000 is near equal to the C1682. Notes on the ZLS website seem to point to this.

Recent 2.4.x series kernels have an entry labeled 'Cyber2000'. Perhaps this works? One contributor tried and failed.

Ok, there is a userland utility called 'fbset' to change the modes of a framebuffer. Does that work? One contributor said no.

In the sparclinux archives is a report of a user using the 24-bit TCX framebuffer and having success. But TCX chip was in Mr. Coffee, not Krups, and TCX onboard Mr. Coffee had 8-bit max, not 24.

So what is the real scoop with 24-bit color on the Krups? Until others try things and speak up, we don't know.

The Dover is not a SPARC-based JavaStation, which this HOWTO caters to. You must use x86 procedures to make it work properly. You did read the warning in the Dover introduction section, didn't you?

I am receiving multiple reports of kernel load failures with the Dover unit. As more information comes in, this HOWTO will present it.

If you boot a JavaStation via the serial console, the framebuffer console is completely disabled. Is there any way to activate the framebuffer console after booting? (asked on Sparclinux mailing list 2001-05-11).

Not to our knowledge.

You better get busy then.

So ask it. Email <rsd@dubinski-family.org> and I will try to help. If I can not help, I will direct you to the mailing lists or suitable contacts.

Mr. Coffee Jumper Assignments

J0206                   JTAG header, perhaps JSCC compatible. 
J0904   1-2 shortened   Enter POST - output ttya, input ttya 
        1-2 open        Skip POST - output screen, input ttya 
        3-4             Unused 
        5-6             Unused 
        7-8             Unused 
J1101   1-2 open (dflt) TPE squelch 
        1-2 short       Reduced squelch threshold 
J1102   1-2 open (dflt) 100 Ohm TPE termination 
            short       150 Ohm TPE termination 
J1602                   Manufacturing test of unknown sort 
J1603   1-2             PROM select (unfortunately PROM socket is emply) 
        2-3 (default)   Flash select 
J1604   1-2             FPROM write disable 
        2-3 (default)   FPROM write enable 

J0904 block is a bit block of pullup resistors which a user may shorten. 
They may be read from the keyboard controller with a command 0xDD.

Krups Jumper Assignments

J1202   1-2     Use Flash 
        2-3     Select optional diagnostic FLASH PROM in socket J1203 
                (this does not sound quite right ...) 
J1300   1-2     Software debug use 
        3-4     Factory use - PROM switch?? 
        5-6     Unused 
        7-8     Flash update recovery 
J0500           JTAG 

Surprisingly, Sun's website still (as of Oct-31-2001) has the JavaStation press release online at http://www.sun.com/961029/JES/ http://www.sun.com/961029/JES Many thanks to Gary <gary@spiritwars.com> for pointing this out.

Surprisingly, Sun's JavaOS 1.0 environment for the JavaStations is still mirrored about on the Internet even today (Oct-31-2001). JDSE 1.0.1 can be found at: http://sunsite.tut.fi/javastation Many thanks to Gary <gary@spiritwars.com> for pointing this out.

Download the link labeled 'jdse.tar'. JDSE 1.0.1 was one of the first demo version of JavaOS available, and was a free download. Later, downloads were restricted to paying customers. This first version is merely a boot image of JavaOS and the HotJava browser. No telnet or ssh applet, no X Windows applet, no file manager, no email applet, nothing but the browser. Starting to feel boxed in? Welcome to the official software of the JavaStation.

Copies of latter versions of JavaOS as included in the NetraJ software bundle have not been located online yet. This is probably due to the latter versions, namely NetraJ 2 and above, was retail software, and never available for free download from Sun's site.

Pete Zaitcev has written a document describing how to enable IDE on your Espresso model JavaStation. It is included here with Pete's permission.

By Pete Zaitcev
1999/11/01
2000/08/22

I am not responsible for any direct or indirect damages to your
equiment or yourself resulting from you reading this document.
USE THIS INFORMATION ON YOUR OWN RISK.

IDE interrupt line is connected "upside down" on the Espresso.
To have IDE working we need to insert an invertor in it.
We borrow the invertor from ISA IRQ3. If you want to use ISA
modem, set it to use COM3/IRQ4 (please realize that Linux IRQ
level would be programmed in CPU PCIC).

The following picture provides an overhead view:

    +==================== wire 1 =======================+
    #                                                   #
    #           1202                        1200        #            1201
    #        +-------+                   +-------+      #         +-------+
    #       -!  REP  !--14            1 -!  INV  !- 14  #         !       !
    #       -!       !-                 -!       !-     #         !       !
    #       -!       !-                 -!       !-     #         !       !
    #     4 -!       !-                 -!       !--11==+         !       !
    # /---5--!       !-                 -!       !--10====+       !       !
    #/    6--!--\    !-                 -!       !-  9    #       !       !
A-> *     7 -!   \---!---8              -!       !-  8    #       !       !
    !        +-------+   !               +-------+        #       +-------+
    !                    !                                #
    Z                    ! /=========== wire 2 ===========+
    Z                    !/
    Z R2026          B-> +--- ZZZZ ---*
    Z (pullup)               R1208
    !
    *

I recommend to proceed in the following way:

1. Disconnect 1202 5 & 6. Not knowing if I need them I lifted pins with a
model knife. You may just cut them with side cutters.

2. Lift pins 1200 10 & 11 but do not cut them!

3. Run wires from resistor pads "A" to pin 1200 11 and from pad "B" to
   pin 1200 10. Resistor pads are much easier targets for soldering at home
   than pads under pins 1202 5 & 6. I am a software engineer, so I did it
   the easy way.

   I did not bother to glue wires as a decent electronics hacker would do.

   You are all set. Get kernel 2.4, hack drivers/block/Config.in and enjoy!

   P.S. Let me know if you have drawings of hard drive brackets for Espresso.

When booting your JavaStation, there are certain key combinations you can press to enable some boot monitoring functionality.

Javastation Key Combinations

These are the key combinations that allow you to perform the command monitor
functions:
Press left Alt, left Ctrl key, letter; then turn the power on. You have to
have the keys pressed when you turn on the power otherwise it will not work. 

Ctrl-Alt-H Help on chords
Ctrl-Alt-B Show progress banner
Ctrl-Alt-W Show Ether net address and memory size
Ctrl-Alt-D Run diagnostics             

These key combinations do not work with the Mr. Coffee model.

This section contains links to pictures of the JavaStation line.

Front view of Mr. Coffee is at: http://dubinski-family.org/~jshowto/Files/photos/mr_coffee_front_view.jpg

Top view of Mr. Coffee is at: http://dubinski-family.org/~jshowto/Files/photos/mr_coffee_top_view.jpg

Inside view of Mr. Coffee is at: http://dubinski-family.org/~jshowto/Files/photos/mr_coffee_inside_view.jpg

Mr. Coffee white case variation #1 at: http://dubinski-family.org/~jshowto/Files/photos/mr_coffee_white_case_1.jpg

Mr. Coffee white case variation #2 at: http://dubinski-family.org/~jshowto/Files/photos/mr_coffee_white_case_2.jpg

Front view of krups is at: http://dubinski-family.org/~jshowto/Files/photos/krups_front_view.jpg

Side view of krups is at: http://dubinski-family.org/~jshowto/Files/photos/krups_side_view.jpg

Top view of krups is at: http://dubinski-family.org/~jshowto/Files/photos/krups_top_view.jpg

Front view of Espresso is at: http://dubinski-family.org/~jshowto/Files/photos/espresso_front_view.jpg

Side view of Espresso is at: http://dubinski-family.org/~jshowto/Files/photos/espresso_side_view.jpg

Rear view of Espresso is at: http://dubinski-family.org/~jshowto/Files/photos/espresso_rear_view.jpg

Inside view of Espresso is at: http://dubinski-family.org/~jshowto/Files/photos/espresso_inside_view.jpg

See the JavaEngine-1™ at: http://dubinski-family.org/~jshowto/Files/photos/je1_overhead_view.jpg

View of the JavaStation mousepad is at: http://dubinski-family.org/~jshowto/Files/photos/javastation_mousepad.jpg

View of a Lab of JavaStations running Linux is at: http://dubinski-family.org/~jshowto/Files/photos/lab_of_javastations.jpg

JavaStation Prototype at: http://dubinski-family.org/~jshowto/Files/photos/pre_js_1.jpg

JavaStation Prototype Pic 2 at: http://dubinski-family.org/~jshowto/Files/photos/pre_js_2.jpg

JavaStation Prototype Pic 3 at: http://dubinski-family.org/~jshowto/Files/photos/pre_js_3.jpg

"Dover" JavaStation Internal Pic at: http://dubinski-family.org/~jshowto/Files/photos/dover_inside.jpg

JavaStation Cluster of Eric Brower running a parallel POVRay calculation at: http://dubinski-family.org/~jshowto/Files/photos/cluster.jpg

JavaStation/Fox front view at: http://dubinski-family.org/~jshowto/Files/photos/fox_front.jpg

JavaStation/Fox back view at: http://dubinski-family.org/~jshowto/Files/photos/fox_back.jpg

JavaStation/Fox facing view at: http://dubinski-family.org/~jshowto/Files/photos/fox_face.jpg

JavaStation/Fox internal left view at: http://dubinski-family.org/~jshowto/Files/photos/fox_internal_left.jpg

JavaStation/Fox internal right view at: http://dubinski-family.org/~jshowto/Files/photos/fox_internal_right.jpg