1sbus(4) File Formats sbus(4)
2
3
4
6 sbus - configuration files for SBus device drivers
7
9 The SBus is a geographically addressed peripheral bus present on many
10 SPARC hardware platforms. SBus devices are self-identifying — that is
11 to say the SBus card itself provides information to the system so that
12 it can identify the device driver that needs to be used. The device
13 usually provides additional information to the system in the form of
14 name-value pairs that can be retrieved using the DDI property inter‐
15 faces. See ddi_prop_op(9F) for details.
16
17
18 The information is usually derived from a small Forth program stored in
19 the FCode PROM on the card, so driver configuration files should be
20 completely unnecessary for these devices. However, on some occasions,
21 drivers for SBus devices may need to use driver configuration files to
22 augment the information provided by the SBus card. See driver.conf(4)
23 for further details.
24
25
26 When they are needed, configuration files for SBus device drivers
27 should identify the parent bus driver implicitly using the class key‐
28 word. This removes the dependency on the particular bus driver
29 involved since this may be named differently on different platforms.
30
31
32 All bus drivers of class sbus recognise the following properties:
33
34 reg An arbitrary length array where each element of the array
35 consists of a 3-tuple of integers. Each array element
36 describes a logically contiguous mappable resource on the
37 SBus.
38
39 The first integer of each tuple specifies the slot number
40 the card is plugged into. The second integer of each
41 3-tuple specifies the offset in the slot address space
42 identified by the first element. The third integer of
43 each 3-tuple specifies the size in bytes of the mappable
44 resource.
45
46 The driver can refer to the elements of this array by
47 index, and construct kernel mappings to these addresses
48 using ddi_map_regs(9F). The index into the array is
49 passed as the rnumber argument of ddi_map_regs().
50
51 You can use the ddi_get* and ddi_put* family of functions
52 to access register space from a high-level interrupt con‐
53 text.
54
55
56 interrupts An arbitrary length array where each element of the array
57 consists of a single integer. Each array element
58 describes a possible SBus interrupt level that the device
59 might generate.
60
61 The driver can refer to the elements of this array by
62 index, and register interrupt handlers with the system
63 using ddi_add_intr(9F). The index into the array is
64 passed as the inumber argument of ddi_add_intr().
65
66
67 registers An arbitrary length array where each element of the array
68 consists of a 3-tuple of integers. Each array element
69 describes a logically contiguous mappable resource on the
70 SBus.
71
72 The first integer of each tuple should be set to −1,
73 specifying that any SBus slot may be matched. The second
74 integer of each 3-tuple specifies the offset in the slot
75 address space identified by the first element. The third
76 integer of each 3-tuple specifies the size in bytes of
77 the mappable resoure.
78
79 The registers property can only be used to augment an
80 incompletely specified reg property with information from
81 a driver configuration file. It may only be specified in
82 a driver configuration file.
83
84
85
86 All SBus devices must provide reg properties to the system. The first
87 two integer elements of the reg property are used to construct the
88 address part of the device name under /devices.
89
90
91 Only devices that generate interrupts need to provide interrupts prop‐
92 erties.
93
94
95 Occasionally, it may be necessary to override or augment the configura‐
96 tion information supplied by the SBus device. This can be achieved by
97 writing a driver configuration file that describes a prototype device
98 information (devinfo) node specification, containing the additional
99 properties required.
100
101
102 For the system to merge the information, certain conditions must be
103 met. First, the name property must be the same. Second, either the
104 first two integers (slot number and offset) of the two reg properties
105 must be the same, or the second integer (offset) of the reg and regis‐
106 ters properties must be the same.
107
108
109 In the event that the SBus card has no reg property at all, the self-
110 identifying information cannot be used, so all the details of the card
111 must be specified in a driver configuration file.
112
114 Example 1 A sample configuration file.
115
116
117 Here is a configuration file for an SBus card called SUNW,netboard. The
118 card already has a simple FCode PROM that creates name and reg proper‐
119 ties, and will have a complete set of properties for normal use once
120 the driver and firmware is complete.
121
122
123
124 In this example, we want to augment the properties given to us by the
125 firmware. We use the same name property, and use the registers property
126 to match the firmware reg property. That way we don't have to worry
127 about which slot the card is really plugged into.
128
129
130
131 We want to add an interrupts property while we are developing the
132 firmware and driver so that we can start to experiment with interrupts.
133 The device can generate interrupts at SBus level 3. Additionally, we
134 want to set a debug-level property to 4.
135
136
137 #
138 # Copyright (c) 1992, by Sun Microsystems, Inc.
139 #ident "@(#)SUNW,netboard.conf 1.4 92/03/10 SMI"
140 #
141 name="SUNW,netboard" class="sbus"
142 registers=-1,0x40000,64,-1,0x80000,1024
143 interrupts=3 debug-level=4;
144
145
146
148 See attributes(5) for descriptions of the following attributes:
149
150
151
152
153 ┌─────────────────────────────┬─────────────────────────────┐
154 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
155 ├─────────────────────────────┼─────────────────────────────┤
156 │Architecture │SPARC │
157 └─────────────────────────────┴─────────────────────────────┘
158
160 driver.conf(4), attributes(5), ddi_add_intr(9F), ddi_map_regs(9F),
161 ddi_prop_op(9F)
162
163
164 Writing Device Drivers
165
167 The wildcarding mechanism of the registers property matches every
168 instance of the particular device attached to the system. This may not
169 always be what is wanted.
170
171
172
173SunOS 5.11 31 Dec 1996 sbus(4)