Solbourne ROM Monitor commands
Documentation Resources on the ROM Monitor
- The online manual pages have a few items of interest
Environment Variables and Values
The ROM Monitor variables may be set while the OS is running with the eeprom command, or in the ROM Monitor via "setenv" (or with FORTH assignments).
Not all values may be available or used on all models.
- BOOT_SAFE
- If in Secure mode (PASSWD variable is set), then this value allows a
"boot" (boot from value in variable DEFAULTBOOT) to be executed without
knowing the secure ROM password.
- BOOTMODE
- The Mode in which to boot. Acceptable values are:
- AUTO
- Automatically attempt a boot
- MANUAL
- Do not boot until user types a boot command
- CONSOLE (KBUS only)
-
- bw()
- Use the Black and White IO-board framebuffer as the console
- cg()
- Use the first Color (cg30 or cg40) framebuffer as the console
- zs()
- Use the serial port as the console
Could specify using zs(,,0) ttya or
zs(,,1) ttyb
- fb()
- Use the Framebuffer of preference (cg30, cg40, bw20)
- DEFAULTBOOT
- The filename of the boot kernel. Normally set to vmunix
- DEFAULTDUMP
- Device specification of the default dump partition device. In the
form:
[proto.]device([controller, unit, devspecific])
E.G.
sd.si(0,0,1)
- DEFAULTROOT
- Device specification of the default root partition device. In the
form:
[proto.]device([controller, unit, devspecific])
E.G.
sd.si(0,0,0)
- DEFAULTSWAP
- Device specification of the default swap partition device. In the
form:
[proto.]device([controller, unit, devspecific])
E.G.
sd.si(0,0,1)
See the "Boot Commands" section below for details on the intricate nature
of the DEFAULTSWAP variable.
- DIAG-SWITCH?
- hmmm....
- DIAGBOOT
- This string is the fully specified device and file path to a diagnostic
program you wish to use when a KBus system is in "Diag" mode, or when
any system is booted with "boot -d". The normal value for this is
something like sd.si(0,0,6)kvm/stand/dg
- DIAGMODE
- Power-On diagnostics mode. Acceptable values are:
- LONG
- Perform a more extensive diagnostic, including memory test
- SHORT
- Perform a minimal diagnostics check
- DISPLAYRES
- Display resolution of the console frame buffer
- ENETADDR (read only)
- The 6 octet ethernet address. The normal vendor octet triplet for
Solbourne systems was 00:00:8e
- HOSTID (read only)
- The "unique" host identification longword usually used for software
licensing
- INPUT-DEVICE (IDT only)
- keyboard
- ttya
- ttyb
- INSTALLDEV (IDT only)
- Device specification of the default Operating System installation device.
In the form:
[proto.]device([controller, unit, devspecific])
E.G.
st.si(0,0,3)
- INSTALLPATH (IDT only)
- The UNIX filesystem path appended to INSTALLDEV during network installation
- IP_ADDR (IDT only)
- IP Address of this station during network boots
- INSTALLED (IDT only)
- Set this to "0" before installing an Operating System, set to "1" when
the OS is installed
- KBD_LAYOUT
- This variable is akin to the Sun type 4 keyboard DIP pack for setting the
"keyboard language identity", this variable may be set to any of:
COUNTRY HEX VALUE
------- ---------
US 00
FRANCE_BELGIUM 02
CANADA_FRENCH 03
DENMARK 04
GERMANY 05
ITALY 06
NETHERLANDS 07
NORWAY 08
PORTUGAL 09
SPAIN_LATINAMERICA 0a
SWEDEN_FINLAND 0b
SWITZERLAND_FRENCH 0c
SWITZERLAND_GERMAN 0d
UK 0e
JAPAN 20
- MASTER (KBUS only)
- Slot number of the Master CPU. Generally not set by the user, unless
you specifically wish to override selection of the lowest numbered
slot cpu location. (mainly for diagnostic testing)
- MODEL (read only) [not really]
- Model name of system. Generally Specified as
Series4,5,5E,6/[5679]0n, where n is the number of cpus.
For example:
ROM> setenv MODEL Series6/908
would indicate a KBus machine in a 900 chassis with 8 Series6 cpus
Additionally, i think i've seen the nomenclature for the middle digit
of the Chassis spec indicating something like the number of MCAB boards
installed.
- OUTPUT-DEVICE (IDT only)
- screen
- ttya
- ttyb
- NOSPINNER
- Supress "N Pages Left" in dumps and savecore processing.
- PASSWD
- Encrypted value of a security password
- RAMTEST_#MB (IDT only?)
- The Number of Megabytes to test when the DIAGMODE variable was set
to "long"
- SBUS-PROBE-LIST (IDT only)
- This envvar tells the system
in what order to probe the SBUS slots for devices. The SBUS slots
are numbered starting with 1 closest to the power-supply.
If OUTPUT-DEVICE is set to screen, the
last frame buffer found in the system will be
used as the console output device.
An example setting for a system with a frame buffer in all 3 sbus slots
for which you want the one in SBUS slot 2 to be the console using
OUTPUT-DEVICE as screen would be
setenv SBUS-PROBE-LIST 132
so SBus slot 2, being the last probed, will handle the console.
- Note :
- by changing ordering in the kernel configuration file,
you can force a specific ordering of like-type devices, since i'm not
sure the kernel probe routines pay any attention to SBUS-PROBE-LIST.
For example:
device bwtwo1 at obio ? csr 0x00001000 priority 6
device bwtwo0 at obio ? csr 0x00001000 priority 6
will allocate bwtwo1 prior to bwtwo0 giving you the opposite effect
of the default.
- SCREEN-#COLUMNS
- Number of columns the screen has for the ROM console driver
- SCREEN-#ROW
- Number of rows the screen has for the ROM console driver
- SERIAL (read only)
- Serial Number
some of the systems we got from Solbourne had Serial Numbers like
ncc1701, hyuck, hyuck
- SI_NSPERBYTE
- allows slowing down the SCSI bus by limiting the maximum synchronous
transfer rate that will be negotiated in nanoseconds per byte.
A 5MB/sec rate translates into 200ns per byte. Setting this variable to
300 will slow the bus to 3.33MB/sec.
- STDOUT_PATH
- hmm...
- SUNMON-COMPAT? or SUNMON
- Like the Sun OpenBootProm setting, this defines on S4000 series systems
whether to use the standard Solbourne ROM Monitor command set, or to
use Solbourne's FORTH (minimal compatibility with Sun's) Monitor.
- TRUE
- Use the old style monitor
- FALSE
- Use the FORTH-alike monitor
- SVn_MODE
- sets modes for the Cougar SCSI controller. See the _MANUAL(sv(4))
manual page for details.
- TTYA_MODE
- TTYB_MODE
- These variables set the operating mode for the TTY ports when used
in console mode. An example setting might be:
setenv TTYA_MODE 9600,8,n,1
- TZ
- Timezone string in System V format
- UNAME
- Allows the 'uname' command to return a different format. If set to
'sun', 'uname' will return a sun compatible output like:
SunOS foo 4.1.3 3 sun4
This can be very beneficial for lame-brain software (like AcroRead, etc)
that think's it's smarter than you and refuses to run on a '4.1C' machine
(stupid shell-script case statements are easy to modify, also)
- VME_RORA
- Inform kernel that there is a VME Release on Register Access (RORA)
interrupter on the VME bus. If set to 1 the OS calls interrupt handler
routines immediately. Otherwise the OS queues VME interrupt requests
for later processing.
Boot Commands
The boot command syntax is as follows:
boot [ filename ] [ -nbaws ] [ -f filename ] [ -- ] arg
or
boot -d
boot -d (diagnostic boot) is of most use on the S4000 Series, since it has
no DIAG switch (unless you have the tricorder which i'm sure you
don't -- but if you do, can i please have it?). This command will use
the value in the DIAGBOOT variable to boot.
Without arguments, boot uses the values in the DEFAULTBOOT and DIAGBOOT
environment variables
Because the Solbourne BootRoms have builtin Boot Code for UFS partitions,
there's no need to 'installboot' on Solbournes (actually, you can't) to
build a boot block. Additionally, this allows use of the ROM Monitor 'ls'
command to view UFS partition contents.
Another thing to watch out for is that a standard kernel (with default
swap spec) will use the value in the ROM variable DEFAULTSWAP,
instead of the "b" partition of the root device. You can hose yourself
if you aren't careful.
Also, if DEFAULTSWAP doesn't exist, the default kernel sends out a
bootparam request to find its swap device. This can be hard to figure
out if you don't know what to watch for.
Other ROM Commands
cp copy
Example:
cp sd.si(,,)etc/fstab fb()
to copy the fstab to the console, because you can't remember what
partition something was on. Anything copied to the console this way
also ends up in the dmesg buffer. per 'dworkin'
dmesg
dmesg sploots the current message buffer contents to your
console/output-device.
last modified on Tue Sep 7 19:30:45 MDT 1999
Stephen Dowdy