Commit | Line | Data |
---|---|---|
15637ed4 RG |
1 | .\" Copyright (c) 1983 The Regents of the University of California. |
2 | .\" All rights reserved. | |
3 | .\" | |
4 | .\" Redistribution and use in source and binary forms, with or without | |
5 | .\" modification, are permitted provided that the following conditions | |
6 | .\" are met: | |
7 | .\" 1. Redistributions of source code must retain the above copyright | |
8 | .\" notice, this list of conditions and the following disclaimer. | |
9 | .\" 2. Redistributions in binary form must reproduce the above copyright | |
10 | .\" notice, this list of conditions and the following disclaimer in the | |
11 | .\" documentation and/or other materials provided with the distribution. | |
12 | .\" 3. All advertising materials mentioning features or use of this software | |
13 | .\" must display the following acknowledgement: | |
14 | .\" This product includes software developed by the University of | |
15 | .\" California, Berkeley and its contributors. | |
16 | .\" 4. Neither the name of the University nor the names of its contributors | |
17 | .\" may be used to endorse or promote products derived from this software | |
18 | .\" without specific prior written permission. | |
19 | .\" | |
20 | .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND | |
21 | .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | |
22 | .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE | |
23 | .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE | |
24 | .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL | |
25 | .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS | |
26 | .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) | |
27 | .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT | |
28 | .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY | |
29 | .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF | |
30 | .\" SUCH DAMAGE. | |
31 | .\" | |
32 | .\" @(#)6.t 6.3 (Berkeley) 4/17/91 | |
33 | .\" | |
34 | .\".ds RH "Adding New Devices | |
35 | .ne 2i | |
36 | .NH | |
37 | ADDING NEW SYSTEM SOFTWARE | |
38 | .PP | |
39 | This section is not for the novice, it describes | |
40 | some of the inner workings of the configuration process as | |
41 | well as the pertinent parts of the system autoconfiguration process. | |
42 | It is intended to give | |
43 | those people who intend to install new device drivers and/or | |
44 | other system facilities sufficient information to do so in the | |
45 | manner which will allow others to easily share the changes. | |
46 | .PP | |
47 | This section is broken into four parts: | |
48 | .IP \(bu 3 | |
49 | general guidelines to be followed in modifying system code, | |
50 | .IP \(bu 3 | |
51 | how to add non-standard system facilities to 4.3BSD, | |
52 | .IP \(bu 3 | |
53 | how to add a device driver to 4.3BSD, and | |
54 | .IP \(bu 3 | |
55 | how UNIBUS device drivers are autoconfigured under 4.3BSD on the VAX. | |
56 | .NH 2 | |
57 | Modifying system code | |
58 | .PP | |
59 | If you wish to make site-specific modifications to the system | |
60 | it is best to bracket them with | |
61 | .DS | |
62 | #ifdef SITENAME | |
63 | \&... | |
64 | #endif | |
65 | .DE | |
66 | to allow your source to be easily distributed to others, and | |
67 | also to simplify \fIdiff\fP\|(1) listings. If you choose not | |
68 | to use a source code control system (e.g. SCCS, RCS), and | |
69 | perhaps even if you do, it is | |
70 | recommended that you save the old code with something | |
71 | of the form: | |
72 | .DS | |
73 | #ifndef SITENAME | |
74 | \&... | |
75 | #endif | |
76 | .DE | |
77 | We try to isolate our site-dependent code in individual files | |
78 | which may be configured with pseudo-device specifications. | |
79 | .PP | |
80 | Indicate machine-specific code with ``#ifdef vax'' (or other machine, | |
81 | as appropriate). | |
82 | 4.2BSD underwent extensive work to make it extremely portable to | |
83 | machines with similar architectures\- you may someday find | |
84 | yourself trying to use a single copy of the source code on | |
85 | multiple machines. | |
86 | .PP | |
87 | Use \fIlint\fP periodically if you make changes to the system. | |
88 | The 4.3BSD kernel has only two lines of lint in it. It | |
89 | is very simple to lint the kernel. Use the LINT configuration | |
90 | file, designed to pull in as much of the kernel source code as | |
91 | possible, in the following manner. | |
92 | .DS | |
93 | $ cd /sys/conf | |
94 | $ mkdir ../LINT | |
95 | $ config LINT | |
96 | $ cd ../LINT | |
97 | $ make depend | |
98 | $ make assym.s | |
99 | $ make \-k lint > linterrs 2>&1 & | |
100 | (or for users of \fIcsh\fP\|(1)) | |
101 | % make \-k >& linterrs | |
102 | .DE | |
103 | This takes about an hour on a lightly loaded | |
104 | VAX-11/750, but is well worth it. | |
105 | .NH 2 | |
106 | Adding non-standard system facilities | |
107 | .PP | |
108 | This section considers the work needed to augment | |
109 | .IR config 's | |
110 | data base files for non-standard system facilities. | |
111 | .I Config | |
112 | uses a set of files that list the source modules that may be required | |
113 | when building a system. | |
114 | The data bases are taken from the directory in which | |
115 | .I config | |
116 | is run, normally /sys/conf. | |
117 | Three such files may be used: | |
118 | .IR files , | |
119 | .IR files .machine, | |
120 | and | |
121 | .IR files .ident. | |
122 | The first is common to all systems, | |
123 | the second contains files unique to a single machine type, | |
124 | and the third is an optional list of modules for use on a specific machine. | |
125 | This last file may override specifications in the first two. | |
126 | The format of the | |
127 | .I files | |
128 | file has grown somewhat complex over time. Entries are normally of | |
129 | the form | |
130 | .IP | |
131 | .nf | |
132 | .DT | |
133 | \fIdir/source.c\fP \fItype\fP \fIoption-list\fP \fImodifiers\fP | |
134 | .LP | |
135 | for example, | |
136 | .IP | |
137 | .nf | |
138 | .DT | |
139 | \fIvaxuba/foo.c\fP \fBoptional\fP foo \fBdevice-driver\fP | |
140 | .LP | |
141 | The | |
142 | .I type | |
143 | is one of | |
144 | .B standard | |
145 | or | |
78ed81a3 | 146 | .B optional . |
15637ed4 RG |
147 | Files marked as standard are included in all system configurations. |
148 | Optional file specifications include a list of one or more system | |
149 | options that together require the inclusion of this module. | |
150 | The options in the list may be either names of devices that may | |
151 | be in the configuration file, | |
152 | or the names of system options that may be defined. | |
153 | An optional file may be listed multiple times with different options; | |
154 | if all of the options for any of the entries are satisfied, | |
155 | the module is included. | |
156 | .PP | |
157 | If a file is specified as a | |
158 | .IR device-driver , | |
159 | any special compilation options for device drivers will be invoked. | |
160 | On the VAX this results in the use of the | |
161 | .B \-i | |
162 | option for the C optimizer. This is required when pointer references | |
163 | are made to memory locations in the VAX I/O address space. | |
164 | .PP | |
165 | Two other optional keywords modify the usage of the file. | |
166 | .I Config | |
167 | understands that certain files are used especially for | |
168 | kernel profiling. These files are indicated in the | |
169 | .I files | |
170 | files with a | |
171 | .I profiling-routine | |
172 | keyword. For example, the current profiling subroutines | |
173 | are sequestered off in a separate file with the following | |
174 | entry: | |
175 | .IP | |
176 | .nf | |
177 | .DT | |
178 | \fIsys/subr_mcount.c\fP \fBoptional\fP \fBprofiling-routine\fP | |
179 | .fi | |
180 | .LP | |
181 | The | |
182 | .I profiling-routine | |
183 | keyword forces | |
184 | .I config | |
185 | not to compile the source file with the | |
186 | .B \-pg | |
187 | option. | |
188 | .PP | |
189 | The second keyword which can be of use is the | |
190 | .I config-dependent | |
191 | keyword. This causes | |
192 | .I config | |
193 | to compile the indicated module with the global configuration | |
194 | parameters. This allows certain modules, such as | |
195 | .I machdep.c | |
196 | to size system data structures based on the maximum number | |
197 | of users configured for the system. | |
198 | .NH 2 | |
199 | Adding device drivers to 4.3BSD | |
200 | .PP | |
201 | The I/O system and | |
202 | .I config | |
203 | have been designed to easily allow new device support to be added. | |
204 | The system source directories are organized as follows: | |
205 | .DS | |
206 | .TS | |
207 | lw(1.0i) l. | |
208 | /sys/h machine independent include files | |
209 | /sys/sys machine-independent system source files | |
210 | /sys/conf site configuration files and basic templates | |
211 | /sys/net network-protocol-independent, but network-related code | |
212 | /sys/netinet DARPA Internet code | |
213 | /sys/netimp IMP support code | |
214 | /sys/netns Xerox NS code | |
215 | /sys/vax VAX-specific mainline code | |
216 | /sys/vaxif VAX network interface code | |
217 | /sys/vaxmba VAX MASSBUS device drivers and related code | |
218 | /sys/vaxuba VAX UNIBUS device drivers and related code | |
219 | .TE | |
220 | .DE | |
221 | .PP | |
222 | Existing block and character device drivers for the VAX | |
223 | reside in ``/sys/vax'', ``/sys/vaxmba'', and ``/sys/vaxuba''. Network | |
224 | interface drivers reside in ``/sys/vaxif''. Any new device | |
225 | drivers should be placed in the appropriate source code directory | |
226 | and named so as not to conflict with existing devices. | |
227 | Normally, definitions for things like device registers are placed in | |
228 | a separate file in the same directory. For example, the ``dh'' | |
229 | device driver is named ``dh.c'' and its associated include file is | |
230 | named ``dhreg.h''. | |
231 | .PP | |
232 | Once the source for the device driver has been placed in a directory, | |
233 | the file ``/sys/conf/files.machine'', and possibly | |
234 | ``/sys/conf/devices.machine'' should be modified. The | |
235 | .I files | |
236 | files in the conf directory contain a line for each C source or binary-only | |
237 | file in the system. Those files which are machine independent are | |
238 | located in ``/sys/conf/files,'' while machine specific files | |
239 | are in ``/sys/conf/files.machine.'' The ``devices.machine'' file | |
240 | is used to map device names to major block device numbers. If the device | |
241 | driver being added provides support for a new disk | |
242 | you will want to modify this file (the format is obvious). | |
243 | .PP | |
244 | In addition to including the driver in the | |
245 | .I files | |
246 | file, it must also be added to the device configuration tables. These | |
247 | are located in ``/sys/vax/conf.c'', or similar for machines other than | |
248 | the VAX. If you don't understand what to add to this file, you should | |
249 | study an entry for an existing driver. | |
250 | Remember that the position in the | |
251 | device table specifies the major device number. | |
252 | The block major number is needed in the ``devices.machine'' file | |
253 | if the device is a disk. | |
254 | .PP | |
255 | With the configuration information in place, your configuration | |
256 | file appropriately modified, and a system reconfigured and rebooted | |
257 | you should incorporate the shell commands needed to install the special | |
258 | files in the file system to the file ``/dev/MAKEDEV'' or | |
259 | ``/dev/MAKEDEV.local''. This is discussed in the document ``Installing | |
260 | and Operating 4.3BSD on the VAX''. | |
261 | .NH 2 | |
262 | Autoconfiguration on the VAX | |
263 | .PP | |
264 | 4.3BSD requires all device drivers to conform to a | |
265 | set of rules which allow the system to: | |
266 | .IP 1) | |
267 | support multiple UNIBUS and MASSBUS adapters, | |
268 | .IP 2) | |
269 | support system configuration at boot time, and | |
270 | .IP 3) | |
271 | manage resources so as not to crash when devices request | |
272 | resources which are unavailable. | |
273 | .LP | |
274 | In addition, devices such as the RK07 which require | |
275 | everyone else to get off the UNIBUS when they are running | |
276 | need cooperation from other DMA devices if they are to work. | |
277 | Since it is unlikely that you will be writing a device driver | |
278 | for a MASSBUS device, this section is devoted exclusively to | |
279 | describing the I/O system and autoconfiguration process as it | |
280 | applies to UNIBUS devices. | |
281 | .PP | |
282 | Each UNIBUS on a VAX has a set of resources: | |
283 | .IP \(bu | |
284 | 496 map registers which are used to convert from the 18-bit UNIBUS | |
285 | addresses into the much larger VAX memory address space. | |
286 | .IP \(bu | |
287 | Some number of buffered data paths (3 on an 11/750, 15 on an 11/780, 0 | |
288 | on an 11/730) which are used by high speed devices to transfer | |
289 | data using fewer bus cycles. | |
290 | .LP | |
291 | There is a structure of type \fIstruct uba_hd\fR in the system per UNIBUS | |
292 | adapter used to manage these resources. This structure also contains | |
293 | a linked list where devices waiting for resources to complete DMA UNIBUS | |
294 | activity have requests waiting. | |
295 | .PP | |
296 | There are three central structures in the writing of drivers for UNIBUS | |
297 | controllers; devices which do not do DMA I/O can often use only two | |
298 | of these structures. The structures are \fIstruct uba_ctlr\fR, the | |
299 | UNIBUS controller structure, \fIstruct uba_device\fR the UNIBUS | |
300 | device structure, and \fIstruct uba_driver\fR, the UNIBUS driver structure. | |
301 | The \fIuba_ctlr\fR and \fIuba_device\fR structures are in | |
302 | one-to-one correspondence with the definitions of controllers and | |
303 | devices in the system configuration. | |
304 | Each driver has a \fIstruct uba_driver\fR structure specifying an internal | |
305 | interface to the rest of the system. | |
306 | .PP | |
307 | Thus a specification | |
308 | .DS | |
309 | controller sc0 at uba0 csr 0176700 vector upintr | |
310 | .DE | |
311 | would cause a \fIstruct uba_ctlr\fR to be declared and initialized in | |
312 | the file \fIioconf.c\fR for the system configured from this description. | |
313 | Similarly specifying | |
314 | .DS | |
315 | disk up0 at sc0 drive 0 | |
316 | .DE | |
317 | would declare a related \fIuba_device\fR in the same file. | |
318 | The \fIup.c\fR driver which implements this driver specifies in | |
319 | its declarations: | |
320 | .DS | |
321 | int upprobe(), upslave(), upattach(), updgo(), upintr(); | |
322 | struct uba_ctlr *upminfo[NSC]; | |
323 | struct uba_device *updinfo[NUP]; | |
324 | u_short upstd[] = { 0776700, 0774400, 0776300, 0 }; | |
325 | struct uba_driver scdriver = | |
326 | { upprobe, upslave, upattach, updgo, upstd, "up", updinfo, "sc", upminfo }; | |
327 | .DE | |
328 | initializing the \fIuba_driver\fR structure. | |
329 | The driver will support some number of controllers named \fIsc0\fR, \fIsc1\fR, | |
330 | etc, and some number of drives named \fIup0\fR, \fIup1\fR, etc. where the | |
331 | drives may be on any of the controllers (that is there is a single | |
332 | linear name space for devices, separate from the controllers.) | |
333 | .PP | |
334 | We now explain the fields in the various structures. It may help | |
335 | to look at a copy of \fIvaxuba/ubareg.h\fR, \fIvaxuba/ubavar.h\fR and drivers | |
336 | such as \fIup.c\fR and \fIdz.c\fR while reading the descriptions of | |
337 | the various structure fields. | |
338 | .SH | |
339 | uba_driver structure | |
340 | .PP | |
341 | One of these structures exists per driver. It is initialized in | |
342 | the driver and contains functions used by the configuration program | |
343 | and by the UNIBUS resource routines. The fields of the structure are: | |
344 | .IP \fBud_probe\fP | |
345 | A routine which, given a \fIcaddr_t\fR address as argument, | |
346 | should attempt to determine that the device is present | |
347 | at that address in virtual memory, | |
348 | and should cause an interrupt from the device. | |
349 | When probing controllers, two additional arguments are supplied: | |
350 | the controller index, and a pointer to the \fIuba_ctlr\fP structure. | |
351 | Device probe routines receive a pointer to the \fIuba_device\fP structure | |
352 | as second argument. | |
353 | Both of these structures are described below. | |
354 | Neither is normally used, but devices that must record status or device | |
355 | type information from the probe routine may require them. | |
356 | .PP | |
357 | The autoconfiguration routine attempts to verify that the specified address | |
358 | responds before calling the probe routine. | |
359 | However, the device may not actually exist or may be of a different type, | |
360 | and therefore the probe routine should use delays | |
361 | (via the DELAY(n) macro which delays for \fIn\fR microseconds) rather than | |
362 | waiting for specific events to occur. The routine must \fBnot\fR | |
363 | declare its argument as a \fIregister\fR parameter, but \fBmust\fR declare | |
364 | .DS | |
365 | register int br, cvec; | |
366 | .DE | |
367 | as local variables. At boot time the system takes special measures | |
368 | that these variables are ``value-result'' parameters. The \fIbr\fR | |
369 | is the IPL of the device when it interrupts, and the \fIcvec\fR | |
370 | is the interrupt vector address on the UNIBUS. These registers | |
371 | are actually filled in in the interrupt handler when an interrupt occurs. | |
372 | .IP | |
373 | As an example, here is the \fIup.c\fR | |
374 | probe routine: | |
375 | .DS | |
376 | upprobe(reg) | |
377 | caddr_t reg; | |
378 | { | |
379 | register int br, cvec; | |
380 | ||
381 | #ifdef lint | |
382 | br = 0; cvec = br; br = cvec; upintr(0); | |
383 | #endif | |
384 | ((struct updevice *)reg)->upcs1 = UP_IE|UP_RDY; | |
385 | DELAY(10); | |
386 | ((struct updevice *)reg)->upcs1 = 0; | |
387 | return (sizeof (struct updevice)); | |
388 | } | |
389 | .DE | |
390 | The definitions for \fIlint\fR serve to indicate to it that the | |
391 | \fIbr\fR and \fIcvec\fR variables are value-result. | |
392 | The call to the interrupt routine satisfies lint that the interrupt | |
393 | handler is used. | |
394 | The cod here enable interrupts on the device and write the ready bit UP_RDY. | |
395 | The 10 microsecond delay insures that the interrupt enable will | |
396 | not be canceled before the interrupt can be posted. The return of | |
397 | ``sizeof (struct updevice)'' here indicates that the probe routine | |
398 | is satisfied that the device is present (the value returned is not | |
399 | currently used, but future plans dictate that you should return the amount | |
400 | of space in the device's register bank). A probe routine may use | |
401 | the function ``badaddr'' to see | |
402 | if certain other addresses are accessible on the UNIBUS (without generating | |
403 | a machine check), or look at the contents of locations where certain | |
404 | registers should be. If the registers contents are not acceptable or | |
405 | the addresses don't respond, the probe routine can return 0 and the | |
406 | device will not be considered to be there. | |
407 | .IP | |
408 | One other thing to note is that the action of different VAXen when illegal | |
409 | addresses are accessed on the UNIBUS may differ. Some of the machines | |
410 | may generate machine checks and some may cause UNIBUS errors. Such | |
411 | considerations are handled by the configuration program and the driver | |
412 | writer need not be concerned with them. | |
413 | .IP | |
414 | It is also possible to write a very simple probe routine for a one-of-a-kind | |
415 | device if probing is difficult or impossible. Such a routine would include | |
416 | statements of the form: | |
417 | .DS | |
418 | br = 0x15; | |
419 | cvec = 0200; | |
420 | .DE | |
421 | for instance, to declare that the device ran at UNIBUS br5 and interrupted | |
422 | through vector 0200 on the UNIBUS. | |
423 | .IP \fBud_slave\fP | |
424 | This routine is called with a \fIuba_device\fR structure (yet to | |
425 | be described) and the address of the device controller. It should | |
426 | determine whether a particular slave device of a controller is | |
427 | present, returning 1 if it is and 0 if it is not. | |
428 | As an example here is the slave routine for \fIup.c\fR. | |
429 | .DS | |
430 | upslave(ui, reg) | |
431 | struct uba_device *ui; | |
432 | caddr_t reg; | |
433 | { | |
434 | register struct updevice *upaddr = (struct updevice *)reg; | |
435 | ||
436 | upaddr->upcs1 = 0; /* conservative */ | |
437 | upaddr->upcs2 = ui->ui_slave; | |
438 | if (upaddr->upcs2 & UPCS2_NED) { | |
439 | upaddr->upcs1 = UP_DCLR | UP_GO; | |
440 | return (0); | |
441 | } | |
442 | return (1); | |
443 | } | |
444 | .DE | |
445 | Here the code fetches the slave (disk unit) number from the \fIui_slave\fR | |
446 | field of the \fIuba_device\fR structure, and sees if the controller | |
447 | responds that that is a non-existent driver (NED). If the drive is not present, | |
448 | a drive clear is issued to clean the state of the controller, and 0 is | |
449 | returned indicating that the slave is not there. Otherwise a 1 is returned. | |
450 | .IP \fBud_attach\fP | |
451 | The attach routine is called after the autoconfigure code and the driver concur | |
452 | that a peripheral exists attached to a controller. This is the routine | |
453 | where internal driver state about the peripheral can be initialized. | |
454 | Here is the \fIattach\fR routine from the \fIup.c\fR driver: | |
455 | .DS | |
456 | .DT | |
457 | upattach(ui) | |
458 | register struct uba_device *ui; | |
459 | { | |
460 | register struct updevice *upaddr; | |
461 | ||
462 | if (upwstart == 0) { | |
463 | timeout(upwatch, (caddr_t)0, hz); | |
464 | upwstart++; | |
465 | } | |
466 | if (ui->ui_dk >= 0) | |
467 | dk_mspw[ui->ui_dk] = .0000020345; | |
468 | upip[ui->ui_ctlr][ui->ui_slave] = ui; | |
469 | up_softc[ui->ui_ctlr].sc_ndrive++; | |
470 | ui->ui_type = upmaptype(ui); | |
471 | } | |
472 | .DE | |
473 | The attach routine here performs a number of functions. The first | |
474 | time any drive is attached to the controller it starts the timeout | |
475 | routine which watches the disk drives to make sure that interrupts | |
476 | aren't lost. It also initializes, for devices which have been assigned | |
477 | \fIiostat\fR numbers (when ui->ui_dk >= 0), the transfer rate of the | |
478 | device in the array \fIdk_mspw\fR, the fraction of a second it takes | |
479 | to transfer 16 bit word. It then initializes an inverting pointer | |
480 | in the array \fIupip\fR which will be used later to determine, for a | |
481 | particular \fIup\fR controller and slave number, the corresponding | |
482 | \fIuba_device\fR. It increments the count of the number of devices | |
483 | on this controller, so that search commands can later be avoided | |
484 | if the count is exactly 1. It then attempts to decipher the actual | |
485 | type of drive attached to the controller in a controller-specific | |
486 | way. On the EMULEX SC-21 it may ask for the number of tracks on | |
487 | the device and use this to decide what the drive type is. The drive | |
488 | type is used to setup disk partition mapping tables and other | |
489 | device specific information. | |
490 | .IP \fBud_dgo\fP | |
491 | .br | |
492 | This is the routine which is called by the UNIBUS resource management | |
493 | routines when an operation is ready to be started (because the required | |
494 | resources have been allocated). The routine in \fIup.c\fR is: | |
495 | .DS | |
496 | updgo(um) | |
497 | struct uba_ctlr *um; | |
498 | { | |
499 | register struct updevice *upaddr = (struct updevice *)um->um_addr; | |
500 | ||
501 | upaddr->upba = um->um_ubinfo; | |
502 | upaddr->upcs1 = um->um_cmd|((um->um_ubinfo>>8)&0x300); | |
503 | } | |
504 | .DE | |
505 | This routine uses the field \fIum_ubinfo\fR of the \fIuba_ctlr\fR | |
506 | structure which is where the UNIBUS routines store the UNIBUS | |
507 | map allocation information. In particular, the low 18 bits of this | |
508 | word give the UNIBUS address assigned to the transfer. The assignment | |
509 | to \fIupba\fR in the go routine places the low 16 bits of the UNIBUS | |
510 | address in the disk UNIBUS address register. The next assignment | |
511 | places the disk operation command and the extended (high 2) address | |
512 | bits in the device control-status register, starting the I/O operation. | |
513 | The field \fIum_cmd\fR was initialized with the command to be stuffed | |
514 | here in the driver code itself before the call to the \fIubago\fR | |
515 | routine which eventually resulted in the call to \fIupdgo\fR. | |
516 | .IP \fBud_addr\fP | |
517 | This is a zero-terminated list of the conventional addresses | |
518 | for the device control registers in UNIBUS space. | |
519 | This information is used by the system | |
520 | to look for instances of the device supported by the driver. | |
521 | When the system probes for the device it first checks for a | |
522 | control-status register located at the address indicated in | |
523 | the configuration file (if supplied), then uses the list of | |
524 | conventional addresses pointed to be \fIud_addr\fP. | |
525 | .IP \fBud_dname\fP | |
526 | This is the name of a \fIdevice\fR supported by this controller; thus the | |
527 | disks on a SC-21 controller are called \fIup0\fR, \fIup1\fR, etc. | |
528 | That is because this field contains \fIup\fR. | |
529 | .IP \fBud_dinfo\fP | |
530 | This is an array of back pointers to the \fIuba_device\fR structures for | |
531 | each device attached to the controller. Each driver defines a set of | |
532 | controllers and a set of devices. The device address space is always | |
533 | one-dimensional, so that the presence of extra controllers may be | |
534 | masked away (e.g. by pattern matching) to take advantage of hardware | |
535 | redundancy. This field is filled in by the configuration program, | |
536 | and used by the driver. | |
537 | .IP \fBud_mname\fP | |
538 | The name of a controller, e.g. \fIsc\fR for the \fIup.c\fR driver. | |
539 | The first SC-21 is called \fIsc0\fR, etc. | |
540 | .IP \fBud_minfo\fP | |
541 | The backpointer array to the structures for the controllers. | |
542 | .IP \fBud_xclu\fP | |
543 | If non-zero specifies that the controller requires exclusive | |
544 | use of the UNIBUS when it is running. This is non-zero currently | |
545 | only for the RK611 controller for the RK07 disks to map around a hardware | |
546 | problem. It could also be used if 6250bpi tape drives are to be used | |
547 | on the UNIBUS to insure that they get the bandwidth that they need | |
548 | (basically the whole bus). | |
549 | .IP \fBud_ubamem\fP | |
550 | This is an optional entry point to the driver to configure UNIBUS memory | |
551 | associated with a device. | |
552 | If this field in the driver structure is null, it is ignored. | |
553 | Otherwise, it is called before beginning to probe for devices | |
554 | when configuration of a UNIBUS is begun. | |
555 | The driver must probe for the existence of its memory, | |
556 | and is then responsible for allocating the map registers corresponding | |
557 | to the device memory addresses so that the registers are not used for other | |
558 | purposes. | |
559 | The \fBud_ubamem\fP returns 0 on success and \-1 on failure. | |
560 | A return value of 1 indicates that the memory exists, and that there | |
561 | is no further configuration required for the device. | |
562 | .SH | |
563 | uba_ctlr structure | |
564 | .PP | |
565 | One of these structures exists per-controller. | |
566 | The fields link the controller to its UNIBUS adapter and contain the | |
567 | state information about the devices on the controller. The fields are: | |
568 | .IP \fBum_driver\fP | |
569 | A pointer to the \fIstruct uba_device\fR for this driver, which has | |
570 | fields as defined above. | |
571 | .IP \fBum_ctlr\fP | |
572 | The controller number for this controller, e.g. the 0 in \fIsc0\fR. | |
573 | .IP \fBum_alive\fP | |
574 | Set to 1 if the controller is considered alive; currently, always set | |
575 | for any structure encountered during normal operation. That is, the | |
576 | driver will have a handle on a \fIuba_ctlr\fR structure only if the | |
577 | configuration routines set this field to a 1 and entered it into the | |
578 | driver tables. | |
579 | .IP \fBum_intr\fP | |
580 | The interrupt vector routines for this device. These are generated | |
581 | by \fIconfig\fP and this field is initialized in the | |
582 | \fIioconf.c\fR file. | |
583 | .IP \fBum_hd\fP | |
584 | .br | |
585 | A back-pointer to the UNIBUS adapter to which this controller is attached. | |
586 | .IP \fBum_cmd\fP | |
587 | A place for the driver to store the command which is to be given to | |
588 | the device before calling the routine \fIubago\fR with the devices | |
589 | \fIuba_device\fR structure. This information is then retrieved when the | |
590 | device go routine is called and stuffed in the device control status register | |
591 | to start the I/O operation. | |
592 | .IP \fBum_ubinfo\fP | |
593 | Information about the UNIBUS resources allocated to the device. This is | |
594 | normally only used in device driver go routine (as \fIupdgo\fR above) | |
595 | and occasionally in exceptional condition handling such as ECC correction. | |
596 | .IP \fBum_tab\fP | |
597 | This buffer structure is a place where the driver hangs the device structures | |
598 | which are ready to transfer. Each driver allocates a buf structure for each | |
599 | device (e.g. \fIupdtab\fR in the \fIup.c\fR driver) for this purpose. | |
600 | You can think of this structure as a device-control-block, and the | |
601 | buf structures linked to it as the unit-control-blocks. | |
602 | The code for dealing with this structure is stylized; see the \fIrk.c\fR | |
603 | or \fIup.c\fR driver for the details. If the \fIubago\fR routine | |
604 | is to be used, the structure attached to this \fIbuf\fR structure | |
605 | must be: | |
606 | .RS | |
607 | .IP \(bu 3 | |
608 | A chain of \fIbuf\fR structures for each waiting device on this controller. | |
609 | .IP \(bu 3 | |
610 | On each waiting \fIbuf\fR structure another \fIbuf\fR structure which is | |
611 | the one containing the parameters of the I/O operation. | |
612 | .RE | |
613 | .SH | |
614 | uba_device structure | |
615 | .PP | |
616 | One of these structures exist for each device attached to a UNIBUS | |
617 | controller. Devices which are not attached to controllers or which | |
618 | perform no buffered data path | |
619 | DMA I/O may have only a device structure. Thus \fIdz\fR | |
620 | and \fIdh\fR devices have only \fIuba_device\fR structures. | |
621 | The fields are: | |
622 | .IP \fBui_driver\fP | |
623 | A pointer to the \fIstruct uba_driver\fR structure for this device type. | |
624 | .IP \fBui_unit\fP | |
625 | The unit number of this device, e.g. 0 in \fBup0\fR, or 1 in \fBdh1\fR. | |
626 | .IP \fBui_ctlr\fP | |
627 | .br | |
628 | The number of the controller on which this device is attached, or \-1 | |
629 | if this device is not on a controller. | |
630 | .IP \fBui_ubanum\fP | |
631 | The number of the UNIBUS on which this device is attached. | |
632 | .IP \fBui_slave\fP | |
633 | The slave number of this device on the controller which it is attached to, | |
634 | or \-1 if the device is not a slave. Thus a disk which was unit 2 on | |
635 | a SC-21 would have \fIui_slave\fR 2; it might or might not be \fIup2\fR, | |
636 | that depends on the system configuration specification. | |
637 | .IP \fBui_intr\fP | |
638 | .br | |
639 | The interrupt vector entries for this device, copied into the UNIBUS | |
640 | interrupt vector at boot time. The values of these fields are filled | |
641 | in by \fIconfig\fP to small code segments which it | |
642 | generates in the file \fIubglue.s\fR. | |
643 | .IP \fBui_addr\fP | |
644 | The control-status register address of this device. | |
645 | .IP \fBui_dk\fP | |
646 | .br | |
647 | The iostat number assigned to this device. Numbers are assigned to | |
648 | disks only, and are small nonnegative integers which index the various | |
649 | \fIdk_*\fP arrays in <\fIsys/dk.h\fP>. | |
650 | .IP \fBui_flags\fP | |
651 | The optional ``flags \fIxxx\fP'' parameter from the configuration | |
652 | specification was copied to this field, to be interpreted by the driver. | |
653 | If \fIflags\fP was not specified, then this field will contain a 0. | |
654 | .IP \fBui_alive\fP | |
655 | The device is really there. Presently set to 1 when a device is | |
656 | determined to be alive, and left 1. | |
657 | .IP \fBui_type\fP | |
658 | The device type, to be used by the driver internally. | |
659 | .IP \fBui_physaddr\fP | |
660 | The physical memory address of the device control-status register. | |
661 | This is typically used in the device dump routines. | |
662 | .IP \fBui_mi\fP | |
663 | .br | |
664 | A \fIstruct uba_ctlr\fP pointer to the controller (if any) on which | |
665 | this device resides. | |
666 | .IP \fBui_hd\fP | |
667 | .br | |
668 | A \fIstruct uba_hd\fP pointer to the UNIBUS on which this device resides. | |
669 | .SH | |
670 | UNIBUS resource management routines | |
671 | .PP | |
672 | UNIBUS drivers are supported by a collection of utility routines | |
673 | which manage UNIBUS resources. If a driver attempts to bypass the | |
674 | UNIBUS routines, other drivers may not operate properly. | |
675 | The major routines are: \fIuballoc\fP to allocate UNIBUS resources, | |
676 | \fIubarelse\fP to release previously allocated resources, and | |
677 | \fIubago\fP to initiate DMA. When allocating UNIBUS resources | |
678 | you may request that you | |
679 | .IP NEEDBDP | |
680 | if you need a buffered data path, | |
681 | .IP HAVEBDP | |
682 | if you already have a buffered data path and just want new | |
683 | mapping registers (and access to the UNIBUS), | |
684 | .IP CANTWAIT | |
685 | if you are calling (potentially) from interrupt level, and | |
686 | .IP NEED16 | |
687 | if the device uses only 16 address bits, and thus requires | |
688 | map registers from the first 64K of UNIBUS address space. | |
689 | .LP | |
690 | If the presentation here does not answer all the questions | |
691 | you may have, consult the file /sys/vaxuba/uba.c | |
692 | .SH | |
693 | Autoconfiguration requirements | |
694 | .PP | |
695 | Basically all you have to do is write a \fIud_probe\fP and a \fIud_attach\fP | |
696 | routine for the controller. It suffices to have a \fIud_probe\fP routine | |
697 | which just initializes \fIbr\fP and \fIcvec\fP, and a \fIud_attach\fP | |
698 | routine which does nothing. | |
699 | Making the device fully configurable requires, of course, more work, | |
700 | but is worth it if you expect the device to be in common usage | |
701 | and want to share it with others. | |
702 | .PP | |
703 | If you managed to create all the needed hooks, then make sure you include | |
704 | the necessary header files; the ones included by \fIvaxuba/ct.c\fP are nearly | |
705 | minimal. Order is important here, don't be surprised at undefined structure | |
706 | complaints if you order the includes incorrectly. | |
707 | Finally, if you get the device configured in, you can try bootstrapping | |
708 | and see if configuration messages print out about your device. | |
709 | It is a good idea to have some messages in the probe routine so that | |
710 | you can see that it is being called and what is going on. | |
711 | If it is not called, then you probably have the control-status | |
712 | register address wrong in the system configuration. The autoconfigure | |
713 | code notices that the device doesn't exist in this case, | |
714 | and the probe will never be called. | |
715 | .PP | |
716 | Assuming that your probe routine works and you manage | |
717 | to generate an interrupt, then you are basically back to where you | |
718 | would have been under older versions of UNIX. | |
719 | Just be sure to use the \fIui_ctlr\fP field of the \fIuba_device\fP | |
720 | structures to address the device; compiling in funny constants | |
721 | will make your driver only work on the CPU type you have (780, 750, or 730). | |
722 | .PP | |
723 | Other bad things that might happen while you are setting up the configuration | |
724 | stuff: | |
725 | .IP \(bu 3 | |
726 | You get ``nexus zero vector'' errors from the system. This will happen | |
727 | if you cause a device to interrupt, but take away the interrupt enable | |
728 | so fast that the UNIBUS adapter cancels the interrupt and confuses | |
729 | the processor. The best thing to do it to put a modest delay in the | |
730 | probe code between the instructions which should cause and interrupt and | |
731 | the clearing of the interrupt enable. (You should clear interrupt | |
732 | enable before you leave the probe routine so the device doesn't interrupt | |
733 | more and confuse the system while it is configuring other devices.) | |
734 | .IP \(bu 3 | |
735 | The device refuses to interrupt or interrupts with a ``zero vector''. | |
736 | This typically indicates a problem with the hardware or, for devices | |
737 | which emulate other devices, that the emulation is incomplete. Devices | |
738 | may fail to present interrupt vectors because they have configuration | |
739 | switches set wrong, or because they are being accessed in inappropriate ways. | |
740 | Incomplete emulation can cause ``maintenance mode'' features to not work | |
741 | properly, and these features are often needed to force device interrupts. |