The Purpose of this Document

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 <dubinski@mscs.mu.edu>, Computer Technician and UNIX systems administrator for Marquette University's Math, Statistics and Computer Science Department. In the MU MSCS department, 125 JavaStations are currently running Linux, configured using the information, techniques and files presented in this document.

In early 1999, Eric Brower <ebrower@mscs.mu.edu> 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.

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

Acknowledgments

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:

• Pete Zaitcev <zaitcev@metabyte.com> (JavaStation kernel mod author)

• Eric Brower <ebrower@usa.net> (XFree mods and author of the original embedded-build HOWTO)

• Varol Kaptan <varol@ulakbim.gov.tr> (made available his Krups images and patches. Backported kernel support to 2.2.x series)

• David Miller <davem@redhat.com> (the original Linux/SPARC kernel porter)

• The Linux/SPARC kernel porters and mailing list

• The thousands of contributors to the Linux kernel

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

Document Contributors

The following people have contributed to this specific document:

• Pete Zaitcev <zaitcev@metabyte.com> (Proofreading and factual corrections of initial drafts)

• Magdalena Wodzinska <magdalena.wodzinska@marquette.edu> (Proofreading and document layout suggestions)

History of this document

Document Copyright and Licenses

This particular document and its source as a whole is Copyright 1999-2000, Robert Dubinski <dubinski@mscs.mu.edu>. You may mirror or redistribute this document as a whole or in part for either public or commercial purposes provided the following: 1) you do not make any modifications to this work , 2) retain this license information and author copyright section, even when redistributing just a part of this document, and 3) include acknowledgement of where this document as a whole may be obtained . This ensures that any comments written by the document author do not get taken out of context or modified incorrectly, acknowledges the work of the author, allows for inclusion in commercial projects, and points readers to where they may find potentially updated versions of the information presented.

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 <dubinski@mscs.mu.edu> or send me a patch to the document source, and corrections will be made immediately.

In the future, this document may be re-released under the Open Content or other Free Document license, but for now all Open Documentation licenses are currently being investigated by the author. If you have comments into this legal matter, drop the author a line at <dubinski@mscs.mu.edu>. As it stands, the license presented above captures the spirit of the LDP boilerplate license without specifically mentioning it.

This document is a member document of the Linux Documentation Project.

Location of the Latest Version and Source

The latest online version of this document can be found at: http://www.mscs.mu.edu/~tech/Linux_on_JS .

The pre-processed SGML source to this document, written to the Docbook DTD, is available from: http://www.mscs.mu.edu/~tech/Linux_on_JS/Files/JavaStation-HOWTO.sgml

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

What is a JavaStation NC?

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.

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 or the Linux OS.

Definition of an NC including the Differentiation from PC's

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:

• "Zero-Administration". (Add a new NC and it will get everything it needs off the network, without an admin ever needing to visit it.)

• Lower Total-Cost-of-Ownership (TCO) (No internal hard drives, floppy drives or CD players reduces form-factor, repair expenses, selling price and thus total-cost-of-ownership.)

• Access to all web-based apps as well as "legacy" X and MS Windows apps.

• Quick upgrades (just upgrade your server and the changes propogate throughout)

• Longer lifespan (just upgrade the software, growing hard disk and memory requirements is not an issue)

• Smaller OS footprint (when running brower-based apps)

Disadvantages of NC's:

• No local access to data files (all your files stored on a remote server)

• Requires fast, stable networks

Description of the JavaStation Model Line including Hardware Specs

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.

Reasons for Running Linux and NC Myths Dispelled

It turns out that Linux makes the JavaStations perform more than adequately on the desktop. Thanks to the kernel work of Pete Zaitcev <zaitcev@metabyte.com> with mods and documentation contributed by others, 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:

• Diskless X-Terminal. (Gives the JavaStations the capability of the Sun Xterminal 1 hardware that they replaced).

• The NC solution, Linux-style: local X + a java-capable browser can make the JavaStations perform like they did with JavaOS/HotJava, only many times faster.

• A beowulf node, or a dedicated RC5/SETI@HOME client. The JavaStation running Linux makes a stable, long-lasting number cruncher.

• A small, standalone machine. While a task more suited on today's low-cost machines, there's not much that prevents the JavaStation from performing as a full-fleged standalone UNIX machine by itself. Just remember to set your expectations appropriately when doing so; they were "low-budget" clients when they were sold, and should not be directly compared to today's workstation offerings.

• A router and server, as Pete Zaitcev <zaitcev@metabyte.com> demonstrates as possible with his Espresso model JavaStation decked out with IDE disk and ethernet card.

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 has killed the line in favor of the Sun Ray. While the performance of the Sun Ray is good, keep in mind it is not a dedicated computing device and is little more than a graphics display hanging off your Sun server, which can give you some unexpected 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.

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 PROM's and the like.

Why JavaStations are No Longer Produced

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.

As the Sun Ray is not an NC in the traditional sense (it is merely a framebuffer, and not a computing device itself), there is no explanation why the two do not co-exist.

In talking to the users of the JavaStations, 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.

Where to Purchase a JavaStation

Since Sun has canceled production of the JavaStation line, it no longer sells them through their official channels. It should be possible to order any remaining JavaStation stock from the Sun Spares site at http://www.sunspares.com.

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. Search around the auction sites like Ebay and Yahoo Auctions, and you should be able to turn some up.

Lastly, a great resource for JavaStations is "Bodoman's JavaStation site" at: http://www.bodoman.com/javastation/javastation.html . Here you can find Mr. Coffee and Krups models.

The current going price as of May 2000 for a Mr. Coffee model without memory or monitor is about $70-100US, while the Krups goes for about $85-100US. Anything more is typically due to memory pre-installed. Since the Taiwanese earthquake of 1999, memory prices have fluctuated on a near daily basis, making it difficult to pin a price range down in this manner.

You might also get lucky and stumble on someone who wants to get rid of JavaStations cheap. Pete Zaitcev <zaitcev@metabyte.com> purchased a 32-MB Krups for $75US in a pristine unopened box.

Complete Hardware Requirements

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, the Sun SparcLinux server is needed 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.

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 example kernels and filesystems for you to use, eliminating your need of a Linux/SPARC server, but you still need a server of some type to feed the image to the JavaStations as they boot.

Network Service Requirements

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.

Understand the JavaStation Boot Sequence

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:

1. C: "Who am I?"

2. S: "You are xxx"

3. C: "Where do I go for my boot image?"

4. S: "You go here."

5. C: "Give me my image from here...Please?"

6. S: "Here's your image."

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.

Additional Software Requirements: Replacement Firmware (PROLL)

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, kernel hacker Pete Zaitcev <zaitcev@metabyte.com> wrote a complete PROM replacement called PROLL.

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 Pete Zaitcev's website at: http://www.metabyte.com/~zaitcev/linux.

The current version at the time of this writing is "11".

PROLL can also be found mirrored on "VGER", and also on this HOWTO's distribution site at: http://www.mscs.mu.edu/~tech/Linux_on_JS/Files/proll_11.tar.gz (HOWTO website mirror)".

Decide on your Filesystem: NFS-Root, or Embedded?

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

Before you begin

This chapter assumes you wish to compile your own Linux kernel for the JavaStation. It assumes you already know how to compile Linux kernels in general, perhaps on 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, this HOWTO assumes you do it on a Linux/Sparc based server running in 32-bit mode.

Make sure you use 32-bit mode

When compiling your own JavaStation-capable kernel, you need to make sure the Sun server you are working on is set to 32-bit mode. So, if you're on an Ultra-class machine, be sure you 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.

Supported Linux Kernel Versions

The kernel source revision you should use depends on which model of JavaStation you have.

Mr. Coffee support has worked 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. Pete Zaitcev <zaitcev@metabyte.com> added Krups support in the early 2.3.x sequence, but the MMU changes to the 32-bit SPARC kernel kept it from compiling cleanly until later on. The kernel is known to compile cleanly with the Mar. 17 CVS kernel, and should compile cleanly with any 2.3.99pre3+ version kernel. Krups support has been backported by Varol Kapton <varol@ulakbim.gov.tr>, and it is fully supported in the 2.2.15-prepatch versions.

By the time this document gets widespread exposure, it is hoped that the 2.4.x stable kernel cycle will be ready, at which time any 2.4.x kernel should compile cleanly with support for the entire JavaStation line.

If you can not get a kernel to compile, you should try the samples pointed to by this document.

Required Kernel Configuration Options

When you do your make config command to enter the kernel configuration stage, there are a few things you are required to enable:

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 

You can get a working ".config" file which has these options set later in this chapter.

Necessary Patch for "Embedded-Root" FS Configurations

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 RAMdisk 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 change by 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://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/ramdisk_patch

It should 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 "TroubleShooting" section of this document.

Build the JavaStation-Ready Kernel

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.

JavaStation-Ready Kernel Images and ".config" File Samples

Here are some sample ".config" and JavaStation-ready kernel images. They have been donated by Linux-running JavaStation users.

Preparing Yourself to Build Your Own Filesystem

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.

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

1. Start with an established distribution's filesystem and whittle down to the core.

2. Start with an established distribution's "rescue disk" filesystem and add desired functionality.

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.

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 and Debian distributions are good starting points.

Contents of the "/etc/fstab" File

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
###

The "Embedded-Root" Image Creation Procedure

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:

1. Prototype Your Filesystem

   This whole chapter deals with rolling your own filesystem. In this step, it is assumed you create your own filesystem, perhaps by prototyping one on a working "NFS-Root" filesystem configuration.

   One thing to keep in mind is that unlike your "NFS-Root" filesystem, the "Embedded-Root" filesystem must fit within the confines of your allocated RAMdisk, generally 4-16 MB. Your maximum size is dependant on the setting of the RAMdisk driver.

2. Create an Empty File for Your FileSystem

   You now need to create a file-based filesystem "container". This is just a file that is the size of your RAMdisk.

   To create this, try the dd command:

   dd if=/dev/zero of=./fs_test.img bs=1k count=8000

   Using this example, you now should have an 8 MB file named "fs_test.img". Note: Be sure the count you use matches the RAMdisk size you allocated for in the kernel's RAMdisk driver!

3. Format your Filesystem "Container"

   Now that you have a "container" for your filesystem, it is time to format it and place a bare filesystem on it.

   In our kernel phase, we added in support for the ext2 filesystem. We'll now format our "container" with this filesystem type.

   mkfs.ext2 ./fs_test.img

   Ignore any warnings about the file not being a block device, and proceed anyway. This is an expected warning message.

4. Mount the Filesystem "Container" and Write to It

   Now that you have your filesystem container, you can mount it and load your prototyped filesystem on it.

   To mount the container, use the kernel loopback device. Make sure your server's kernel has loopback support enabled and issue a:

   mount -o loop ./fs_test.img /mnt

   Copy your files to the filesystem, and make sure "/etc/fstab" has the RAMdisk entries as described elsewhere in this document.

   To avoid symbolic links being changed into actual copies of files, use a copy tool like "tar" or "cpio" instead of a "cp".

5. Unmount and Compress the Root Filesystem

   Unmount the root filesystem you just created.

   umount /mnt

   Compress the filesystem file with maximum "gzip" compression levels.

   gzip -v9 ./fs_test.img

   You should now have "fs_test.img.gz" file.

6. Hook the Root-Filesystem Onto the Back of Your Kernel Image

   Now you must append the filesystem image onto your kernel.

   You do this with a utility program called "piggyback". The piggyback program takes care of the task of appending the two and letting the kernel know where both it and the filesystem begins and ends.

   The "piggyback" program is found in your kernel source tree under <LINUXROOT>/arch/sparc/boot. It might also be found on your favorite ftp.kernel.org site.

   For piggyback to work, it needs your AOUT format kernel image, the System.map file from your kernel source root directory, and the compressed root-filesystem you just created.

   We put it all together with a:

   piggyback vmlinux.aout System.map fs_test.img.gz

   Be sure to backup your kernel image first, as piggyback used the same "vmlinux.aout" filename for output. Check the filesize of your "vmlinux.aout" file after giving this command and you can verify the filesystem has indeed been appended.

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

Sample FileSystems

Here are some sample filesystems for you to start with.

A filesystem image contributed by Varol Kapton <varol@ulakbim.gov.tr> is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/jsroot_varol.tar.gz

Preface

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".

Setting up the RARP service

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 at start-up (Linux/SPARC has no RARP daemon, per se):

### 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
###

Setting up the DHCP service

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

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.

Pete Zaitcev sent a longer dhcpd.conf for demonstration purposes.

Set up NFS service ("NFS-Root Options" Only)

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.

Setting up for Boot with TFTP

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

The Last Configuration Step

The last step to configuring your Linux-running JavaStation: boot it and cross your fingers!

When booting, the message "The file just loaded does not appear to be executable." Why?

This symptom likely means you forgot to run elftoaout on your kernel image.

Cannot Boot an "Embedded-Root" image > 10 MB on my JavaStation. Why?

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.

Pete Zaitcev <zaitcev@metabyte.com>, author of PROLL answers this can be fixed if needed by someone, as the source to PROLL has been released under 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 by "luck"!

After Booting, Typing Anything Yields Garbage Characters. Why?

There are a few possibilities for this. Among them:

1. You have an incorrect device # for tty0.

2. A "keytable" loaded is incorrect. Make sure you use "sun" instead of "PC" if you use the keytable program. Look for the keytable configuration file if it exists.

In X Sessions to a Solaris server, the font server "xfs" crashes. Why?

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 architecture and point your JavaStations there, or to upgrade your Solaris to the 2.7 11/99 maintenance release or Solaris 8 which both have fixes to this problem.

Performing Indirect XDMCP to a Solaris Server Results in Session Login Failures. Why?

Congratulations! You must 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.

Regarding RARP: Is it Needed or Not?

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

This document explains how to set up kernel-level RARP for the remaining models. In kernel versions 2.3.x/2.4.x, kernel-level RARP support is removed. Pete Zaitcev <zaitcev@metabyte.com> has made a patch to ANK userland RARP that allows it to compile on Linux/SPARC. It is available from: ftp://corp.metabyte.com/private/linux_roxy/tools/". 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.

Can One Use the Smart Card Reader on the Espresso models?

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.

Can One Use the Solaris DHCP server instead of ISC?

Yes, this is possible. Earlier ISC daemons had problems, while the Solaris server was more robust. 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 java01  # JavaStation
010800208E4CF6 03 192.168.128.2  192.168.128.100 java02  # JavaStation

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

##
# First, some network info
#
Locale   m  :UTCoffst=21600:
studsys  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=studsys:JOSchksm=0x155dbf97:Rootpath=/tftpboot:BootFile=proll.mrcoffee:BootSrvA=192.168.128.100:TFTPsrvN=lnxserv:
SUNW.Linux.Krups m :Include=studsys: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:
#
#
#
###

Can One Pass Arguments to "/sbin/init" in a Diskless Boot like This?

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)

Enabling X on the JavaStation

Enabling X on the JavaStation is possible.

First, be sure you have enabled the appropriate framebuffer device in your kernel's configuration (as described elsewhere in this document).

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, like the samples pointed to below.

As of this time, XFree 4.0 does not work on the SPARC line. You'll need to use an XFree 3.3.x variant in the meantime. The new driver model of 4.0 will provide the path necessary to provide a dedicated accellerated X server for the JavaStations.

Sample XFree Sun Frambuffer X Server File is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/XF86_FBDev

Sample XFree JavaStation-Ready XF86Config File is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/XF86Config

Is There Mailing List Help?

There is a mailing devoted exclusively to running Linux on SPARC processor based machines like the JavaStations.

The mailing list address is "sparclinux@vger.rutgers.edu". You should first subscribe to it by sending a message to "majordomo@vger.rutgers.edu" 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 Linux/Sparc mailing list are kept at: http://www.progressive-comp.com/Lists/?l=linux-sparc&r=1&w=2"

Are There Alternate Help Sources Available?

There are a few known sources of Linux on JavaStation help outside of this HOWTO and the Linux/Sparc mailing list.

1. Pete Zaitcev <zaitcev@metabyte.com> was the driving force in programming the Linux kernel support for the JavaStation line. He maintains a website of low-level hardware details at http://corp.metabyte.com/~zaitcev/linux. Here you will find all kinds of little source patches, though none presented are necessary for basic JavaStation support as described in this document.

Additional sources of information will be added as they appear.

Does "Piggyback" work for the x86 too?

Enquiring minds want to know.

Where Can One Find Espressos for Sale?

Enquiring minds want to know.

Do Tools Exist to Configure Net Boot Entries Quickly?

Enquiring minds want to know.

Mr. Coffee Jumper Info

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 Info

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 

JavaStation Photo Gallery

This section contains links to pictures of the JavaStation line.

Front view of Mr. Coffee is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/mr_coffee_front_view.jpg

Top view of Mr. Coffee is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/mr_coffee_top_view.jpg

Inside view of Mr. Coffee is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/mr_coffee_inside_view.jpg

Mr. Coffee white case variation #1 at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/mr_coffee_white_case_1.jpg

Mr. Coffee white case variation #2 at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/mr_coffee_white_case_2.jpg

Front view of krups is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/krups_front_view.jpg

Side view of krups is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/krups_side_view.jpg

Top view of krups is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/krups_top_view.jpg

Front view of Espresso is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/espresso_front_view.jpg

Side view of Espresso is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/espresso_side_view.jpg

Rear view of Espresso is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/espresso_rear_view.jpg

Inside view of Espresso is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/espresso_inside_view.jpg

See the JavaEngine-1 at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/je1_overhead_view.jpg

View of the JavaStation mousepad is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/javastation_mousepad.jpg

View of a Lab of JavaStations running Linux is at: http://studsys.mscs.mu.edu/~tech/Linux_on_JS/Files/lab_of_javastations.jpg