Introduction (sparc- and sun3-specific), Diskless NetBSD HOW-TO

Sun Firmware procedures

Which Sun machines can netboot

All sparc and sun3 workstations and servers are capable of booting over a network interface. A network boot-strap procedure can be started by entering the appropriate PROM command. The exact format of the PROM command that must be used is dependent on the PROM's version (see below).

There are currently two supported JavaStation models, the JavaStation-1 and the JavaStation-NC. Some JavaStation-1 units have OpenBoot PROM 2, and you should follow the directions below. Some JavaStation-1 and all JavaStation-NC units have Open Firmware. You should read this separate page on Open Firmware-based JavaStation Diskless NetBSD HOW-TO.

sparc64 systems also netboot in a slightly different manner. Go to the page on Open Firmware-based sparc64 Diskless NetBSD HOW-TO.

Determining your ethernet hardware address

When you power on your machine, it will print out its MAC address. If it claims your ethernet address is ff:ff:ff:ff:ff:ff, then your NVRAM battery is dead. See the Sun NVRAM/Hostid FAQ. Your system will not netboot without a working NVRAM.

Obtaining an IP address via RARP

When instructed to boot "over the net", your workstation will first try to acquire an IP address by using the Reverse ARP (or RARP) protocol. Thus you need to run a RARP server somewhere in the same network broadcast domain as your workstation. The ethernet address of the machine (needed when setting up the RARP server) should be displayed in the banner when it is powered on or reset.

Sometimes the arp entry gets corrupt on the rarpd server. If this happens, you may need to run (on the rarpd server):

# arp -s client.test.net CC:CC:CC:CC:CC:CC temp

Note: if the client doesn't detect a rarpd server, it will patiently wait for one and will not display any error messages (as described in the rarpd pages).

Downloading the boot loader

If the RARP phase is completed successfully, the firmware in the workstation expects to be able to download a program via the TFTP protocol. It will do this by setting up a TFTP connection to the server that answered the earlier RARP request, and asking for a file named based on the machine's IP address and architectural class. Sun 3's (verified for 3/50's and 3/60's) may omit the architectural class from the file name.

Naming the boot loader

The netbooting machine will ask via tftp for a file named as follows:

The first eight characters are obtained by converting the four octets of the IP address into hexadecimal representation.
For a sparc and newer sun3 machines, a dot (`.') is appended, followed by the machine's architectural class, in uppercase.

You can use bc(1) to calculate this name as follows:

$ bc
obase=16
192
C0
168
A8
1
1
10
A
quit

Thus, a sun4c machine or a newer sun3 machine which has been assigned IP address 192.168.1.10, will make an TFTP request for `C0A8010A.SUN4C', while an older sun3 machine with the same IP address will request `C0A8010A'.

Normally, it is arranged on the TFTP server that this file is a symbolic link to an appropriate second-stage boot program, which should of course be located in a place where the TFTP daemon can find it (remember, many TFTP daemons run in a chroot'ed environment). You can find the second-stage boot program in installation/netboot/boot.net (sparc) or installation/netboot/netboot (sun3) in the NetBSD distribution.

Firmware commands

These depend on the version of the Openboot firmware.

Version 1 usually has a '>' prompt, and
Version 2 usually responds with an 'ok' prompt

The kernel to load and other arguments can be passed to the boot loader by specifying them on the end of the command line.

Version 1 Openboot firmware

Uses the following syntax to initiate a a boot-strap procedure on a network device:

`b xx()' where xx is a two-letter device specifier, e.g. `b le(,,)' or `b ie(0,0,0)'

The complete syntax is:

`b [[!][[device([controller],[unit],[partition])pgm [arg1,...,arg7]]]/?]' Boot pgm using a default boot sequence device, an EEPROM-specified device, or a user-specified device, or view the list of available boot devices ('?'). If argument '!' is present, the system won't be reset prior to booting. Up to seven optional arguments will then be passed to the booting program.
The (controller,unit,partition) arguments can be used to specify an TFTP server (???) [If anyone has more details on this, please let us know]

Version 2 Openboot firmware

Uses a generalized syntax to specify the boot device for use with the `boot' command:

`boot net';
this will most likely work in all cases where there is a single network interface on the machine. In this case `net' will have been setup by the firmware as an alias to the full pathname of the on-board network device.
You may want to specify a different kernel name or options. These are listed after the device name:
`boot net netbsd-GENERIC.MP.gz -a'
You may also need to be explicit about the network device you want to use, e.g. because there's more than one interface in the machine, possibly connected to different subnets. In this case, use the full device path name in the boot command, for instance:
`boot /iommu/sbus/lebuffer@2,40000/le@2,60000';
would select the `le' interface located on an "FSBE/S" board in Sbus slot 2; while
`boot /iommu/sbus/ledma:tpe/le';
selects the on-board network interface in twisted-pair mode.

Begin setting things up (suggested order):

Get installation/netboot/boot.net from the NetBSD distribution This is what is sent by TFTP. Copy this file to an appropriately named file in /tftpboot, as described above in the Naming the boot loader section.

Previous | Next | Table of Contents

Home Page

Documentation top level