Device Tree Overview "Go"

transferred from: http://docs.oracle.com/cd/E38902_01/html/E38873/kernelovr-64300.htmlDevice Tree Overview

Devices in the Oracle Solaris OS are represented as interconnected device information node trees. The device tree describes the configuration of a mounted device for a specific computer.

Device Tree Components

The system will generate a tree structure that contains information about the devices that are connected to the computer at boot time. In addition, the device tree can be dynamically reconfigured when the system is running normally. The device tree starts from the root device node that represents the platform.

Below the root node are branches of the device tree. A branch consists of one or more bus node devices and a terminating leaf device.

bus junction devices provide bus mapping and transformation services for subordinate devices in the device tree. PCI-PCI bridges, PCMCIA adapters, and SCSI HBAs are examples of node devices. The discussion of writing a node device driver is limited to the development of SCSI HBA drivers (see Chapter 18th).

leaf devices are typically peripheral devices such as disks, tapes, network adapters, frame buffers, and so on. Leaf device drivers can export traditional character driver interfaces and block driver interfaces. Through these interfaces, user processes can read and write data in a storage device or communication device.

The system uses the following steps to build the tree:

1. The CPU is initialized to search for firmware.

2. The main firmware (OpenBoot, basic input/output systems (Basic input/output system, BIOS), or bootconf) initializes and creates a device tree that contains known or self-identifying hardware.

3. When the primary firmware discovers a compatible firmware in the device, the primary firmware initializes the device and retrieves the device properties.

4. The firmware will find and boot the operating system.

5. The kernel starts at the root node of the tree, searches for a matching device driver, and binds the driver to the device.

6. If the device is a node, the kernel looks for sub-devices that the firmware has not detected. The kernel adds all child devices to the tree under the subtree node.

7. The kernel repeats the process starting at step 5 until no more device nodes are created.

Each driver will export the device operation structure dev_ops(9S) to define what the device driver can do. The device operation structure contains function pointers for common operations such as attach(9E),detach(9E), and GetInfo(9E). The structure also includes a set of function pointers related to specific bus node driver operations, and a set of function pointers related to the operation of a particular leaf node device driver.

The tree structure creates a parent-child relationship between nodes. This parent-child relationship is the key to architecture independence. When a leaf driver or bus node driver essentially relies on an architecture-dependent service, the driver requests its parent to provide the service. This approach allows the driver to function correctly, regardless of the architecture of the computer or processor. A typical device tree is displayed.

Figure 2-2 Example Device tree

Child tree nodes can have one or more child nodes. Leaf nodes represent individual devices.

Display device Tree

The device tree can be displayed in one of three ways:

• The Libdevinfo Library provides programmatic interfaces for accessing device tree content.

• prtconf (1M) command displays the full contents of the device tree.

• The /devices hierarchy is a representation of the device tree. Use the ls(1) command to view the hierarchy.

Note- /devices displays only the devices that have the driver configured on the system. prtconf (1M) command displays all device nodes regardless of whether a device driver exists in the system.

LibdevinfoLibrary

The Libdevinfo Library provides an interface for accessing all common device configuration data. For a list of interfaces, see the libdevinfo(3LIB) man page.

prtconfCommand

The following excerpt of the prtconf(1M) Command example shows all the devices in the system.

System Configuration:sun Microsystems Sun4umemory size:128 Megabytessystem Peripherals (software Nodes): SUNW,Ultra-5_1        0 Packages (driver not attached) Terminal-emulator (driver not attached) Deblocker (driver not attached) OBP-TFTP (Driver not attached) Disk-label (driver not attached) sunw,builtin-drivers (driver not Atta CHED) Sun-keyboard (driver not attached) Ufs-file-system (driver not attached) chosen (driver not attache d) Openprom (driver not attached) client-services (driver not attached) options, instance #0 aliases (driv ER not attached) memory (driver not attached) Virtual-memory (driver not attached) PCI, instance #0 PCI, I                Nstance #0 Ebus, instance #0 Auxio (driver not attached) power, instance #0 SUNW,PLL (driver not attached) SE, instance #0 su, instance #0 su,             Instance #1   Ecpp (Driver not attached) Fdthree, instance #0 EEPROM (driver not attached)            Flashprom (Driver not attached) sunw,cs4231 (driver not attached) network, instance #0                SUNW,M64B (driver not attached) IDE, instance #0 disk (driver not attached)            CDROM (driver not attached) Dad, instance #0 SD, Instance #15 PCI, instance #1                PCI, Instance #0 pci108e,1000 (driver not attached) Sunw,hme, instance #1                    Sunw,isptwo, Instance #0 SD (driver not attached) ST (driver not attached)                    SD, instance #0 (driver not attached) SD, instance #1 (driver not attached)    SD, instance #2 (driver not attached) ... SUNW,ULTRASPARC-III (Driver not attached) SUNW,FFB, instance #0 pseudo,Instance #0 

/devicesDirectory

The /devices hierarchy provides a namespace that represents the device tree. The following is an abbreviated list of /devices namespaces. The sample output corresponds to the previously shown sample device tree and the prtconf(1M) output.

/devices/devices/pseudo/devices/[email protected],0:devctl/devices/sunw,[email protected],0:ffb0/ Devices/[email protected],0/devices/[email protected],0/[email protected],1/devices/[email  protected],0/[email protected],1/sunw,[email protected]:m640/devices/[email protected],0/ [email protected],1/[email protected]:d evctl/devices/[email protected],0/[email protected] , 1/[email protected]:scsi/devices/[email protected],0/[email protected],1/[email protected ]/devices/[email protected],0/[email protected],1/[email protected]/[email protected], 724000:power_button/devices/[email protected],0/[email protected],1/[email protected]/[email  protected],400000:a/devices/[email protected],0/[email protected],1/[email protected]/[ email protected],400000:b/devices/[email protected],0/[email protected],1/[email protected ]/[email protected],400000:0,hdlc/devices/[email protected],0/[email protected],1/[email protected]/[email  protected],400000:1,hdlc/devices/[email protected],0/[email protected],1/[email protected]/[ email protected],400000:a,cu/devices/[email protected],0/[email protected],1/[email  Protected]/[email protected],400000:b,cu/devices/[email protected],0/[email protected],1/[email  protected]/[email protected],3043bc:ecpp0/devices/[email protected],0/[email protected],1 /[email protected]/[email protected],3023f0:a/devices/[email protected],0/[email protected ],1/[email protected]/[email protected],3023f0:a,raw/devices/[email protected],0/[email  protected],1/[email protected]/sunw,[email protected],200000:sound,audio/devices/[email  Protected],0/[email protected],1/[email protected]/sunw,[email protected],200000:sound,audioctl /devices/[email protected],0/[email protected],1/[email protected]/devices/[email protected],0/[email protected],1/[ email protected]/[email protected],0:a/devices/[email protected],0/[email protected],1/[ email protected]/[email protected],0:a,raw/devices/[email protected],0/[email protected],1 /[email protected]/[email protected],0:a/devices/[email protected],0/[email protected],1/[ email protected]/[email protected],0:a,raw/devices/[email protected],0/[email protected]/ Devices/[email protected],0/[email protected]/[email protected]/devices/[email protected], 0/[email protected]/[email protected]/sunw,[email protected]:d evctl/devices/[email  Protected],0/[email protected]/[email protected]/sunw,[email protected]:scsi

To bind a driver to a device

In addition to constructing the device tree, the kernel also determines which drivers are used to manage the device.

Binding a driver to a device refers to the process by which the system chooses a driver to manage a particular device. The binding name is the unique device node name that connects the driver to the device information tree. For each device in the device tree, the system will attempt to select a driver from the list of installed drivers.

Each device node has an associated name property. This property can be specified during system boot through an external agent, such as a PROM, or through a driver.conf configuration file. In either case, the Name property represents the node names assigned to devices in the device tree. The node name is the name that is visible in the /devices side-by-side in the prtconf(1M) output.

Figure 2-3 Device node name

The device node can also have an associated compatible property. The compatible property contains an ordered list of one or more possible driver names or driver aliases for the device.

The system uses the compatible property and the name property to select a driver for the device. If the compatible property exists, the system first attempts to match the contents of the compatible property with the driver in the system. The system will attempt to match the driver name to a known driver in the system, starting with the first driver name in the compatible property list. Each item in the list is processed until a match is found or the end of the list is reached.

If the contents of the name property or the compatible property match a driver in the system, the driver is bound to the device node. If no match is found, no driver is bound to the device node.

Generic device Name

Some devices specify the universal device name as the value of the name property. Generic device names are used to describe the capabilities of a device and do not actually identify a specific driver for the device. For example, a SCSI host bus adapter may have a generic device name of SCSI. Ethernet devices may have generic device name Ethernet.

With the compatible property, the system can determine the alternate driver name for a device with a generic device name, for example,GLM corresponds to a SCSI HBA device driver,HME corresponds to the Ethernet device driver.

Devices with generic device names need to provide the compatible attribute.

Note- for a complete description of generic device names , see IEEE 1275 Open Firmware boot standard firmware boot standards.

A device node with a specific device name is displayed. The driver binding name SUNW,FFB is the same as the device node name.

Figure 2-4 Specific driver node bindings

Displays the device node with the generic device name display. The driver binding name SUNW,FFB is the first name in the compatible property driver list that matches the driver in the list of system drivers. In this case,display is the universal device name for the frame buffer.

Figure 2-5 Generic Driver node bindings

Copyright © ©1992, Inc., Oracle and/or its affiliates. All rights reserved. Legal Notices

Device Tree Overview "Go"