1sbus(4)                          File Formats                          sbus(4)
2
3
4

NAME

6       sbus - configuration files for SBus device drivers
7

DESCRIPTION

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

EXAMPLES

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

ATTRIBUTES

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

SEE ALSO

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

WARNINGS

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)
Impressum