[rescue] rescuing an ailing U10...
mrbill at mrbill.net
Sun Sep 30 01:48:26 CDT 2007
On Sat, Sep 29, 2007 at 09:10:21PM -0700, James Hartley wrote:
> /pci at 1f, 0/pci at 1, 1/ide at 3/cdrom at 2, 0:f
Sun's docs about the "Device Tree":
Device Path Names, Addresses, and Arguments
OpenBoot deals directly with hardware devices in the system. Each device
has a unique name representing the type of device and where that device is
located in the system addressing structure. The following example shows a
full device path name:
/sbus at 1f,0/SUNW,fas at e,8800000/sd at 3,0:a
A full device path name is a series of node names separated by slashes (/).
The root of the tree is the machine node, which is not named explicitly but
is indicated by a leading slash (/). Each node name has the form:
driver-name at unit-address:device-arguments
Table 1-1 describes each of these parameters.
Path Name Parameter Description
A human-readable string consisting of one to 31 letters, digits and
punctuation characters from the set ", . _ + - " that, ideally, has some
mnemonic value. Uppercase and lowercase characters are distinct. In some
cases, this name includes the name of the device's manufacturer and the
device's model name, separated by a comma. Typically, the manufacturer's
upper-case, publicly-listed stock symbol is used as the manufacturer's name
(e.g. SUNW,sd). For built-in devices, the manufacturer's name is usually
omitted (e.g. sbus).
Must precede the address parameter.
A text string representing the physical address of the device in its
parent's address space. The format of the text is bus dependent.
Must precede the arguments parameter.
A text string, whose format depends on the particular device. It can be
used to pass additional information to the device's software.
The full device path name mimics the hardware addressing used by the system
to distinguish between different devices. Thus, you can specify a
particular device without ambiguity.
In general, the unit-address part of a node name represents an address in
the physical address space of its parent. The exact meaning of a particular
address depends on the bus to which the device is attached. Consider this
/sbus at 1f,0/esp at 0,40000/sd at 3,0:a
* 1f,0 represents an address on the main system bus, because the SBus
is directly attached to the main system bus in this example.
* 0,40000 is an SBus slot number (in other words, 0) and an offset (in
other words, 40000), because the esp device is at offset 40000 on the card
in SBus slot 0.
* 3,0 is a SCSI target and logical unit number, because the disk device
is attached to a SCSI bus at target 3, logical unit 0.
When specifying a path name, either the @unit-address or driver-name part
of a node name is optional, in which case the firmware tries to pick the
device that best matches the given name. If there are several matching
nodes, the firmware chooses one (but it may not be the one you want).
For example, using /sbus/esp at 0,40000/sd at 3,0 assumes that the system in
question has exactly one SBus on the main system bus, making sbus as
unambiguous an address as sbus at 1f,0. On the same system, however,
/sbus/esp/sd at 3,0 might or might not be ambiguous. Since SBus accepts
plug-in cards, there could be more than one esp device on the same SBus
bus. If there were more than one on the system, using esp alone would not
specify which one, and the firmware might not choose the one you intended.
As another example, /sbus/@2,1/sd at 3,0 would normally be unambiguous, while
/sbus/scsi at 2,1/@3,0 usually would not, since both a SCSI disk device driver
and a SCSI tape device driver can use the SCSI target, logical unit address
The :device-arguments part of the node name is also optional. Once again,
in the example:
/sbus at 1f,0/scsi at 2,1/sd at 3,0:a
the argument for the disk device is a. The software driver for this device
interprets its argument as a disk partition, so the device path name refers
to partition a on that disk.
Some implementations also enable you to omit path name components. So long
as the omission does not create any ambiguity, those implementations will
select the device that you intended. For example, if our example system had
only one sd device,/sd:a would identify the same device as the much longer
More information about the rescue