SBus Hardware Configuration Files
Hardware configuration files are normally unnecessary for SBus devices. However, on some occasions, drivers for SBus devices need to use hardware configuration files to augment the information provided by the SBus card. See driver.conf(4) and sbus(4) for further details.
Device Issues
This section describes issues with special devices.
Timing-Critical Sections
While most driver operations can be performed without mechanisms for synchronization and protection beyond those provided by the locking primitives, some devices require that a sequence of events occur in order without interruption. In conjunction with the locking primitives, the function ddi_enter_critical(9F) asks the system to guarantee, to the best of its ability, that the current thread will neither be preempted nor interrupted. This stays in effect until a closing call to ddi_exit_critical(9F) is made. See the ddi_enter_critical(9F) man pages for details.
Delays
Many chips specify that they can be accessed only at specified intervals. For example, the Zilog Z8530 SCC has a "write recovery time" of 1.6 microseconds. This means that a delay must be enforced with drv_usecwait(9F) when writing characters with an 8530. In some instances, the specifications do not make explicit what delays are needed, so they must be determined empirically.
Be careful not to compound delays for parts of devices that might exist in large numbers, for example thousands of SCSI disk drives.
Internal Sequencing Logic
Devices with internal sequencing logic map multiple internal registers to the same external address. There are various kinds of internal sequencing logic:
The Intel 8251A and the Signetics 2651 alternate the same external register between two internal mode registers. Writing to the first internal register is accomplished by writing to the external register. This write, however, has the side effect of setting up the sequencing logic in the chip so that the next read/write operation refers to the second internal register.
The NEC PD7201 PCC has multiple internal data registers. To write a byte into a particular register, two steps must be performed. The first step is to write into register zero the number of the register into which the following byte of data will go. The data is then written to the specified data register. The sequencing logic automatically sets up the chip so that the next byte sent will go into data register zero.
The AMD 9513 timer has a data pointer register that points at the data register into which a data byte will go. When sending a byte to the data register, the pointer is incremented. The current value of the pointer register cannot be read.
Interrupt Issues
The following are some common interrupt-related issues:
A controller interrupt does not necessarily indicate that both the controller and one of its slave devices are ready. For some controllers, an interrupt can indicate that either the controller is ready or one of its devices is ready, but not both.
Not all devices power up with interrupts disabled and can begin interrupting at any time.
Some devices do not provide a way to determine that the board has generated an interrupt.
Not all interrupting boards shut off interrupts when told to do so or after a bus reset.
PROM on SPARC Machines
Some platforms have a PROM monitor that provides support for debugging a device without an operating system. This section describes how to use the PROM on SPARC machines to map device registers so that they can be accessed. Usually, the device can be exercised enough with PROM commands to determine if the device is working correctly.
See the boot(1M) man page for a description of the IA boot subsystem.
The PROM has several purposes, including:
Bringing the machine up from power on, or from a hard reset PROM reset command
Providing an interactive tool for examining and setting memory, device registers, and memory mappings
Booting the Solaris system or the kernel debugger kadb(1M)
Simply powering up the computer and attempting to use its PROM to examine device registers can fail. While the device might be correctly installed, those mappings are specific to the Solaris operating environment and do not become active until the Solaris kernel is booted. Upon power up, the PROM maps only essential system devices, such as the keyboard.
Taking a system crash dump using the sync command
Open Boot PROM 3
For complete documentation on the Open Boot PROM, see the Open Boot PROM Toolkit User's Guide and the monitor(1M) man page. The examples in this section refer to a Sun-4u architecture; other architectures might require different commands to perform actions.
Note - The Open Boot PROM is currently used on Sun machines with an SBus or UPA/PCI. The Open Boot PROM uses an "ok" prompt. On older machines, you might have to type `n' to get the "ok" prompt.
If the PROM is in secure mode (the security-mode parameter is not set to none), the PROM password might be required (set in the security-password parameter).
The printenv command displays all parameters and their values.
Help is available with the help command.
EMACS-style command-line history is available. Use Control-N (next) and Control-P (previous) to traverse the history list.
Forth Commands
The Open Boot PROM uses the Forth programming language. This is a stack-based language; arguments must be pushed on the stack before running the correct command (called a word), and the result is left on the stack.
To place a number on the stack, type its value.
ok 57 ok 68 |
To add the two top values on the stack, use the + operator.
ok + |
The result remains on the stack. The stack is shown with the .s word.
ok .s bf |
The default base is hexadecimal. The hex and decimal words can be used to switch bases.
ok decimal ok .s 191 |
See the Forth User's Guide for more information.
Walking the PROMs Device Tree
The commands pwd, cd, and ls walk the PROM device tree to get to the device. The cd command must be used to establish a position in the tree before pwd will work. This example is from an Ultra 1 workstation with a cgsix frame buffer on an SBus.
ok cd / |
To see the devices attached to the current node in the tree, use ls.
ok ls f006a064 SUNW,UltraSPARC@0,0 f00598b0 sbus@1f,0 f00592dc counter-timer@1f,3c00 f004eec8 virtual-memory f004e8e8 memory@0,0 f002ca28 aliases f002c9b8 options f002c880 openprom f002c814 chosen f002c7a4 packages |
The full node name can be used:
ok cd sbus@1f,0 ok ls f006a4e4 cgsix@2,0 f0068194 SUNW,bpp@e,c800000 f0065370 ledma@e,8400010 f006120c espdma@e,8400000 f005a448 SUNW,pll@f,1304000 f005a394 sc@f,1300000 f005a24c zs@f,1000000 f005a174 zs@f,1100000 f005a0c0 eeprom@f,1200000 f0059f8c SUNW,fdtwo@f,1400000 f0059ec4 flashprom@f,0 f0059e34 auxio@f,1900000 f0059d28 SUNW,CS4231@d,c000000 |