Booting Sun SPARC Servers | Sidneys1.com

In early 2022 I got several Sun SPARC servers for free off of a FreeCycle ad: I was recently
called out for not providing any sort of update on those devices… so here we go!

The Devices

NVRAM Woes

Sun SPARC machines store some of their BIOS configuration in a chip called an
NVRAM, a special type of writeable random access memory that does not
clear its contents when the machine powers off. This is usually a small RAM chip with its own internal battery that
recharges when the machine is running. Unfortunately this means that when the devices is powered off for extremely long
periods the NVRAM loses its values. Even more unfortunately, over time the NVRAM battery degrades to the point where it
can no longer be recharged, and every power cycle results in a compete configuration wipe.

Such is the case with my SPARC machines; upon powering on we’re greeted with a sad message.
Incorrect configuration checksum; Ethernet address ff:ff:ff:ff:ff:ff, Host ID: ffffffff. The IDPROM contents are invalid
means that our NVRAM has been cleared (the term IDPROM is a historical artifact – older Sun architectures used a
PROM chip instead of an NVRAM chip). Thankfully, there’s a process in
place to restore it manually by entering NVRAM values by hand. Here’s the general process:

1. Boot your Sun SPARC machine. When you see the The IDPROM contents are invalid message, press STOP+A (STOP is a special key on Sun keyboards). This should drop you to the ok prompt, which is the OpenBoot debugging prompt.
   

2. Now we’re going to poke values into our NVRAM using the mkp command. This command has a format mkp. Here’s the layout of NVRAM, or at least the parts we care about:

   Location(s)	Description
   0	Always 1 (format/version number).
   1	First byte of HostID (machine type).
   2–7	6-byte ethernet address (first three bytes should be 80:00:20).
   8–b	Date of manufacture (can be zeros).
   c–e	Remainder of HostID.
   f	IDPROM checksum – bitwise exclusive-or of locations 0–e.

   So let’s start poking values into NVRAM:

   ok set-defaults
   ok 1 0 mkp
   ok 80 1 mkp
   ok 8 2 mkp
   ok 0 3 mkp
   ok 20 4 mkp
   ok c0 54 mkp
   ok ff 6 mkp
   ok ee 7 mkp
   ok 0 8 mkp
   ok 0 9 mkp
   ok 0 a mkp
   ok 0 b mkp
   ok c0 c mkp
   ok ff d mkp
   ok ee e mkp
   ok 0 f 0 do i idprom@ xor loop f mkp

   Locations	Values
   0–7	0180080020c0ffee
   8–f	00000000c0ffee??

   That last line is a small function that will generate the checksum that goes in location f.

3. Enter banner at the ok prompt. This will print out the system banner, and allow us to
   validate that the values we’ve entered are correct. If all is well, you should see something like this:

   ok banner
   Sun Ultra 1 UPA/SBus (UltraSPARC 167MHz), Keyboard Present
   OpenBoot 3.7, 384 MB memory installed, Serial #12648430.
   Ethernet address 8:0:20:c0:ff:ee, Host ID: 80c0ffee.

   If, instead, you see a message like The IDPROM contents are invalid after the banner, then either the
   checksum is wrong (check that you typed it correctly!) or the first byte of the HostID is incorrect – this byte
   specifies the machine type, and must match the machine you’re trying to boot^{. Don’t forget to re-generate the
   checksum after updating any of these values!}

4. Finally enter reset at the ok prompt, which will restart the boot process. Because we
   haven’t lost power, however, the NVRAM will retain the values we’ve set. Wait for the machine to boot. This can take
   quite a while, especially if there is a lot of RAM in the machine. Pro tip, plugging an ethernet cable between the
   Sun server and another machine can help here – otherwise the Sun server can spend a lot of time complaining about
   SUNW,hme0: Link Down - cable problem?. I plugged the Sun Ultra 1 into a powered on Raspberry Pi 3b
   and it stopped complaining.
5. Eventually you’ll be brought to a Unix login, assuming the machine is running Solaris. If you know the password,
   great; if not, things get tricky^{.
   Once logged in, you can set the date and time (for as long as the machine is
   powered on, anyways) at the root# prompt with date 1004102024 (in format
   mmddHHMMYY).}

Results

Sun Ultra 1 Creator

The Sun Ultra 1 was the first machine I tried to boot, and so far the only one to successfully fully boot.

Sun SPARCstation 20

After some stumbles learning about the machine-type byte in the host ID^{, this machine was able to get past the NVRAM
check, but failed during memory diagnostics. This output repeated for some 10 minutes before I turned the machine off.
For J0301, it looks like the fourth bit of the lowest byte (0b00010000) is faulty, always set to 0b1. For example,
the pattern 0b10100101 (0xa5) becomes 0b10110101 (0xb5). For J0302, something stranger seems to be happening, as
0b10100101 (0xa5) becomes 0x01001010 (0x4a) and 0b11111111 (0xff) becomes 0b11101111 (0xef).}

One fun detail I noticed poking around this machine: there’s a little bear with a top hat silkscreened onto the
motherboard:

Axil Ultima 1

Perhaps the saddest story here, and a testament to the quality and reliability of original Sun hardware, this Sun clone
initially had some struggles booting, and wouldn’t recognize keyboard input. After a couple power cycles, however, it
stopped booting altogether.

Notes

I did start writing a section about my efforts last year to boot NetBSD on this machine. I honestly can’t remember if I
had much luck in the end, and I was having difficulty repeating these steps and running out of time to work on this
project. So I’ve decided to leave this section as-is here at the end; the steps should be technically accurate, but as
I said I haven’t had time to verify them and/or finish writing the section. You can check out
this page from NetBSD
Archived at: Wayback Machine. with more instructions if
you’re really interested.

Et tu, root-e?

Now that we’ve managed to convince our Sun server to begin booting, there’s a few others problems. First, Solaris
doesn’t support DHCP, and cannot get a IP address; second, it also doesn’t have a configuration for its own hostname.
Let’s look at configuring those. Instead of DHCP, Solaris uses RARP,
an older protocol (1984; DHCP was first defined in 1993).

Now, ARP is a link-layer protocol that allows
internet-layer addresses (IPs) to be resolved to link-layer addresses (MACs). Reverse ARP is used to resolve a MAC to
an IP. So, I hooked up a Raspberry Pi 3b with an ethernet cable directly to the Sun server. At boot time, Solaris will
send out a broadcast request with its MAC address (configured via NVRAM) and then will listen for a response to
auto-configure its IP. We can install the rarpd package on our Pi, and configure it to know the IP address associated
with our Sun’s MAC.

Checking man rarpd we can note a few important details: first, an association between MAC addresses and hostnames is
configured in /etc/ethers. Second, an association between hostnames and IPs is read from /etc/hosts (this file
already exist on all Linux systems). Third, there’s a section about “bootable images”:

By default rarpd also checks if a bootable image, of a name starting with the IP address in hexadecimal upper-case
letters, is present in the TFTP boot directory before it decides whether to respond to the RARP request. The
comparison involves exactly the first eight characters, and ignores any additional character. A file name shorter
than eight characters in length is unsuccessful. Typically, 192.168.0.122 would correspond to an image named like
C0A8007A.SUN.

Ok, that’s a lot to chew on, but the gist is that we can do the following:

b8:27:eb:fc:10:0c pi            # Our Pi
08:00:20:c0:ff:ee SUN.TEST.COM  # Our Sun

127.0.0.1    pi            # Our Pi
192.168.6.37 SUN.TEST.COM  # Our Sun

And as for the bootable images, for now we’ll run rarp without that restriction using the -e parameter. We’ll also
use -d so that the daemon stays connected to the TTY and we can continue to see log messages. Make sure the system
service isn’t running with sudo systemctl stop rarpd. Now we can run sudo rarpd -e -d. Now let’s boot again and see
if we get an IP address.