Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | /******************************************************************************* |
2 | * | |
3 | * (c) 1999 by Computone Corporation | |
4 | * | |
5 | ******************************************************************************** | |
6 | * | |
7 | * | |
8 | * PACKAGE: Linux tty Device Driver for IntelliPort II family of multiport | |
9 | * serial I/O controllers. | |
10 | * | |
11 | * DESCRIPTION: Definitions limited to properties of the hardware or the | |
12 | * bootstrap firmware. As such, they are applicable regardless of | |
13 | * operating system or loadware (standard or diagnostic). | |
14 | * | |
15 | *******************************************************************************/ | |
16 | #ifndef I2HW_H | |
17 | #define I2HW_H 1 | |
18 | //------------------------------------------------------------------------------ | |
19 | // Revision History: | |
20 | // | |
21 | // 23 September 1991 MAG First Draft Started...through... | |
22 | // 11 October 1991 ... Continuing development... | |
23 | // 6 August 1993 Added support for ISA-4 (asic) which is architected | |
24 | // as an ISA-CEX with a single 4-port box. | |
25 | // | |
26 | // 20 December 1996 AKM Version for Linux | |
27 | // | |
28 | //------------------------------------------------------------------------------ | |
29 | /*------------------------------------------------------------------------------ | |
30 | ||
31 | HARDWARE DESCRIPTION: | |
32 | ||
33 | Introduction: | |
34 | ||
35 | The IntelliPort-II and IntelliPort-IIEX products occupy a block of eight (8) | |
36 | addresses in the host's I/O space. | |
37 | ||
38 | Some addresses are used to transfer data to/from the board, some to transfer | |
39 | so-called "mailbox" messages, and some to read bit-mapped status information. | |
40 | While all the products in the line are functionally similar, some use a 16-bit | |
41 | data path to transfer data while others use an 8-bit path. Also, the use of | |
42 | command /status/mailbox registers differs slightly between the II and IIEX | |
43 | branches of the family. | |
44 | ||
45 | The host determines what type of board it is dealing with by reading a string of | |
46 | sixteen characters from the board. These characters are always placed in the | |
47 | fifo by the board's local processor whenever the board is reset (either from | |
48 | power-on or under software control) and are known as the "Power-on Reset | |
49 | Message." In order that this message can be read from either type of board, the | |
50 | hardware registers used in reading this message are the same. Once this message | |
51 | has been read by the host, then it has the information required to operate. | |
52 | ||
53 | General Differences between boards: | |
54 | ||
55 | The greatest structural difference is between the -II and -IIEX families of | |
56 | product. The -II boards use the Am4701 dual 512x8 bidirectional fifo to support | |
57 | the data path, mailbox registers, and status registers. This chip contains some | |
58 | features which are not used in the IntelliPort-II products; a description of | |
59 | these is omitted here. Because of these many features, it contains many | |
60 | registers, too many to access directly within a small address space. They are | |
61 | accessed by first writing a value to a "pointer" register. This value selects | |
62 | the register to be accessed. The next read or write to that address accesses | |
63 | the selected register rather than the pointer register. | |
64 | ||
65 | The -IIEX boards use a proprietary design similar to the Am4701 in function. But | |
66 | because of a simpler, more streamlined design it doesn't require so many | |
67 | registers. This means they can be accessed directly in single operations rather | |
68 | than through a pointer register. | |
69 | ||
70 | Besides these differences, there are differences in whether 8-bit or 16-bit | |
71 | transfers are used to move data to the board. | |
72 | ||
73 | The -II boards are capable only of 8-bit data transfers, while the -IIEX boards | |
74 | may be configured for either 8-bit or 16-bit data transfers. If the on-board DIP | |
75 | switch #8 is ON, and the card has been installed in a 16-bit slot, 16-bit | |
76 | transfers are supported (and will be expected by the standard loadware). The | |
77 | on-board firmware can determine the position of the switch, and whether the | |
78 | board is installed in a 16-bit slot; it supplies this information to the host as | |
79 | part of the power-up reset message. | |
80 | ||
81 | The configuration switch (#8) and slot selection do not directly configure the | |
82 | hardware. It is up to the on-board loadware and host-based drivers to act | |
83 | according to the selected options. That is, loadware and drivers could be | |
84 | written to perform 8-bit transfers regardless of the state of the DIP switch or | |
85 | slot (and in a diagnostic environment might well do so). Likewise, 16-bit | |
86 | transfers could be performed as long as the card is in a 16-bit slot. | |
87 | ||
88 | Note the slot selection and DIP switch selection are provided separately: a | |
89 | board running in 8-bit mode in a 16-bit slot has a greater range of possible | |
90 | interrupts to choose from; information of potential use to the host. | |
91 | ||
92 | All 8-bit data transfers are done in the same way, regardless of whether on a | |
93 | -II board or a -IIEX board. | |
94 | ||
95 | The host must consider two things then: 1) whether a -II or -IIEX product is | |
96 | being used, and 2) whether an 8-bit or 16-bit data path is used. | |
97 | ||
98 | A further difference is that -II boards always have a 512-byte fifo operating in | |
99 | each direction. -IIEX boards may use fifos of varying size; this size is | |
100 | reported as part of the power-up message. | |
101 | ||
102 | I/O Map Of IntelliPort-II and IntelliPort-IIEX boards: | |
103 | (Relative to the chosen base address) | |
104 | ||
105 | Addr R/W IntelliPort-II IntelliPort-IIEX | |
106 | ---- --- -------------- ---------------- | |
107 | 0 R/W Data Port (byte) Data Port (byte or word) | |
108 | 1 R/W (Not used) (MSB of word-wide data written to Data Port) | |
109 | 2 R Status Register Status Register | |
110 | 2 W Pointer Register Interrupt Mask Register | |
111 | 3 R/W (Not used) Mailbox Registers (6 bits: 11111100) | |
112 | 4,5 -- Reserved for future products | |
113 | 6 -- Reserved for future products | |
114 | 7 R Guaranteed to have no effect | |
115 | 7 W Hardware reset of board. | |
116 | ||
117 | ||
118 | Rules: | |
119 | All data transfers are performed using the even i/o address. If byte-wide data | |
120 | transfers are being used, do INB/OUTB operations on the data port. If word-wide | |
121 | transfers are used, do INW/OUTW operations. In some circumstances (such as | |
122 | reading the power-up message) you will do INB from the data port, but in this | |
123 | case the MSB of each word read is lost. When accessing all other unreserved | |
124 | registers, use byte operations only. | |
125 | ------------------------------------------------------------------------------*/ | |
126 | ||
127 | //------------------------------------------------ | |
128 | // Mandatory Includes: | |
129 | //------------------------------------------------ | |
130 | // | |
131 | #include "ip2types.h" | |
1da177e4 LT |
132 | |
133 | //------------------------------------------------------------------------- | |
134 | // Manifests for the I/O map: | |
135 | //------------------------------------------------------------------------- | |
136 | // R/W: Data port (byte) for IntelliPort-II, | |
137 | // R/W: Data port (byte or word) for IntelliPort-IIEX | |
138 | // Incoming or outgoing data passes through a FIFO, the status of which is | |
139 | // available in some of the bits in FIFO_STATUS. This (bidirectional) FIFO is | |
140 | // the primary means of transferring data, commands, flow-control, and status | |
141 | // information between the host and board. | |
142 | // | |
143 | #define FIFO_DATA 0 | |
144 | ||
145 | // Another way of passing information between the board and the host is | |
146 | // through "mailboxes". Unlike a FIFO, a mailbox holds only a single byte of | |
147 | // data. Writing data to the mailbox causes a status bit to be set, and | |
148 | // potentially interrupting the intended receiver. The sender has some way to | |
149 | // determine whether the data has been read yet; as soon as it has, it may send | |
150 | // more. The mailboxes are handled differently on -II and -IIEX products, as | |
151 | // suggested below. | |
152 | //------------------------------------------------------------------------------ | |
153 | // Read: Status Register for IntelliPort-II or -IIEX | |
154 | // The presence of any bit set here will cause an interrupt to the host, | |
155 | // provided the corresponding bit has been unmasked in the interrupt mask | |
156 | // register. Furthermore, interrupts to the host are disabled globally until the | |
157 | // loadware selects the irq line to use. With the exception of STN_MR, the bits | |
158 | // remain set so long as the associated condition is true. | |
159 | // | |
160 | #define FIFO_STATUS 2 | |
161 | ||
162 | // Bit map of status bits which are identical for -II and -IIEX | |
163 | // | |
164 | #define ST_OUT_FULL 0x40 // Outbound FIFO full | |
165 | #define ST_IN_EMPTY 0x20 // Inbound FIFO empty | |
166 | #define ST_IN_MAIL 0x04 // Inbound Mailbox full | |
167 | ||
168 | // The following exists only on the Intelliport-IIEX, and indicates that the | |
169 | // board has not read the last outgoing mailbox data yet. In the IntelliPort-II, | |
170 | // the outgoing mailbox may be read back: a zero indicates the board has read | |
171 | // the data. | |
172 | // | |
173 | #define STE_OUT_MAIL 0x80 // Outbound mailbox full (!) | |
174 | ||
175 | // The following bits are defined differently for -II and -IIEX boards. Code | |
176 | // which relies on these bits will need to be functionally different for the two | |
177 | // types of boards and should be generally avoided because of the additional | |
178 | // complexity this creates: | |
179 | ||
180 | // Bit map of status bits only on -II | |
181 | ||
182 | // Fifo has been RESET (cleared when the status register is read). Note that | |
183 | // this condition cannot be masked and would always interrupt the host, except | |
184 | // that the hardware reset also disables interrupts globally from the board | |
185 | // until re-enabled by loadware. This could also arise from the | |
186 | // Am4701-supported command to reset the chip, but this command is generally not | |
187 | // used here. | |
188 | // | |
189 | #define STN_MR 0x80 | |
190 | ||
191 | // See the AMD Am4701 data sheet for details on the following four bits. They | |
192 | // are not presently used by Computone drivers. | |
193 | // | |
194 | #define STN_OUT_AF 0x10 // Outbound FIFO almost full (programmable) | |
195 | #define STN_IN_AE 0x08 // Inbound FIFO almost empty (programmable) | |
196 | #define STN_BD 0x02 // Inbound byte detected | |
197 | #define STN_PE 0x01 // Parity/Framing condition detected | |
198 | ||
199 | // Bit-map of status bits only on -IIEX | |
200 | // | |
201 | #define STE_OUT_HF 0x10 // Outbound FIFO half full | |
202 | #define STE_IN_HF 0x08 // Inbound FIFO half full | |
203 | #define STE_IN_FULL 0x02 // Inbound FIFO full | |
204 | #define STE_OUT_MT 0x01 // Outbound FIFO empty | |
205 | ||
206 | //------------------------------------------------------------------------------ | |
207 | ||
208 | // Intelliport-II -- Write Only: the pointer register. | |
209 | // Values are written to this register to select the Am4701 internal register to | |
210 | // be accessed on the next operation. | |
211 | // | |
212 | #define FIFO_PTR 0x02 | |
213 | ||
214 | // Values for the pointer register | |
215 | // | |
216 | #define SEL_COMMAND 0x1 // Selects the Am4701 command register | |
217 | ||
218 | // Some possible commands: | |
219 | // | |
220 | #define SEL_CMD_MR 0x80 // Am4701 command to reset the chip | |
221 | #define SEL_CMD_SH 0x40 // Am4701 command to map the "other" port into the | |
222 | // status register. | |
223 | #define SEL_CMD_UNSH 0 // Am4701 command to "unshift": port maps into its | |
224 | // own status register. | |
225 | #define SEL_MASK 0x2 // Selects the Am4701 interrupt mask register. The | |
226 | // interrupt mask register is bit-mapped to match | |
227 | // the status register (FIFO_STATUS) except for | |
228 | // STN_MR. (See above.) | |
229 | #define SEL_BYTE_DET 0x3 // Selects the Am4701 byte-detect register. (Not | |
230 | // normally used except in diagnostics.) | |
231 | #define SEL_OUTMAIL 0x4 // Selects the outbound mailbox (R/W). Reading back | |
232 | // a value of zero indicates that the mailbox has | |
233 | // been read by the board and is available for more | |
234 | // data./ Writing to the mailbox optionally | |
235 | // interrupts the board, depending on the loadware's | |
236 | // setting of its interrupt mask register. | |
237 | #define SEL_AEAF 0x5 // Selects AE/AF threshold register. | |
238 | #define SEL_INMAIL 0x6 // Selects the inbound mailbox (Read) | |
239 | ||
240 | //------------------------------------------------------------------------------ | |
241 | // IntelliPort-IIEX -- Write Only: interrupt mask (and misc flags) register: | |
242 | // Unlike IntelliPort-II, bit assignments do NOT match those of the status | |
243 | // register. | |
244 | // | |
245 | #define FIFO_MASK 0x2 | |
246 | ||
247 | // Mailbox readback select: | |
248 | // If set, reads to FIFO_MAIL will read the OUTBOUND mailbox (host to board). If | |
249 | // clear (default on reset) reads to FIFO_MAIL will read the INBOUND mailbox. | |
250 | // This is the normal situation. The clearing of a mailbox is determined on | |
251 | // -IIEX boards by waiting for the STE_OUT_MAIL bit to clear. Readback | |
252 | // capability is provided for diagnostic purposes only. | |
253 | // | |
254 | #define MX_OUTMAIL_RSEL 0x80 | |
255 | ||
256 | #define MX_IN_MAIL 0x40 // Enables interrupts when incoming mailbox goes | |
257 | // full (ST_IN_MAIL set). | |
258 | #define MX_IN_FULL 0x20 // Enables interrupts when incoming FIFO goes full | |
259 | // (STE_IN_FULL). | |
260 | #define MX_IN_MT 0x08 // Enables interrupts when incoming FIFO goes empty | |
261 | // (ST_IN_MT). | |
262 | #define MX_OUT_FULL 0x04 // Enables interrupts when outgoing FIFO goes full | |
263 | // (ST_OUT_FULL). | |
264 | #define MX_OUT_MT 0x01 // Enables interrupts when outgoing FIFO goes empty | |
265 | // (STE_OUT_MT). | |
266 | ||
267 | // Any remaining bits are reserved, and should be written to ZERO for | |
268 | // compatibility with future Computone products. | |
269 | ||
270 | //------------------------------------------------------------------------------ | |
271 | // IntelliPort-IIEX: -- These are only 6-bit mailboxes !!! -- 11111100 (low two | |
272 | // bits always read back 0). | |
273 | // Read: One of the mailboxes, usually Inbound. | |
274 | // Inbound Mailbox (MX_OUTMAIL_RSEL = 0) | |
275 | // Outbound Mailbox (MX_OUTMAIL_RSEL = 1) | |
276 | // Write: Outbound Mailbox | |
277 | // For the IntelliPort-II boards, the outbound mailbox is read back to determine | |
278 | // whether the board has read the data (0 --> data has been read). For the | |
279 | // IntelliPort-IIEX, this is done by reading a status register. To determine | |
280 | // whether mailbox is available for more outbound data, use the STE_OUT_MAIL bit | |
281 | // in FIFO_STATUS. Moreover, although the Outbound Mailbox can be read back by | |
282 | // setting MX_OUTMAIL_RSEL, it is NOT cleared when the board reads it, as is the | |
283 | // case with the -II boards. For this reason, FIFO_MAIL is normally used to read | |
284 | // the inbound FIFO, and MX_OUTMAIL_RSEL kept clear. (See above for | |
285 | // MX_OUTMAIL_RSEL description.) | |
286 | // | |
287 | #define FIFO_MAIL 0x3 | |
288 | ||
289 | //------------------------------------------------------------------------------ | |
290 | // WRITE ONLY: Resets the board. (Data doesn't matter). | |
291 | // | |
292 | #define FIFO_RESET 0x7 | |
293 | ||
294 | //------------------------------------------------------------------------------ | |
295 | // READ ONLY: Will have no effect. (Data is undefined.) | |
296 | // Actually, there will be an effect, in that the operation is sure to generate | |
297 | // a bus cycle: viz., an I/O byte Read. This fact can be used to enforce short | |
298 | // delays when no comparable time constant is available. | |
299 | // | |
300 | #define FIFO_NOP 0x7 | |
301 | ||
302 | //------------------------------------------------------------------------------ | |
303 | // RESET & POWER-ON RESET MESSAGE | |
304 | /*------------------------------------------------------------------------------ | |
305 | RESET: | |
306 | ||
307 | The IntelliPort-II and -IIEX boards are reset in three ways: Power-up, channel | |
308 | reset, and via a write to the reset register described above. For products using | |
309 | the ISA bus, these three sources of reset are equvalent. For MCA and EISA buses, | |
310 | the Power-up and channel reset sources cause additional hardware initialization | |
311 | which should only occur at system startup time. | |
312 | ||
313 | The third type of reset, called a "command reset", is done by writing any data | |
314 | to the FIFO_RESET address described above. This resets the on-board processor, | |
315 | FIFO, UARTS, and associated hardware. | |
316 | ||
317 | This passes control of the board to the bootstrap firmware, which performs a | |
318 | Power-On Self Test and which detects its current configuration. For example, | |
319 | -IIEX products determine the size of FIFO which has been installed, and the | |
320 | number and type of expansion boxes attached. | |
321 | ||
322 | This and other information is then written to the FIFO in a 16-byte data block | |
323 | to be read by the host. This block is guaranteed to be present within two (2) | |
324 | seconds of having received the command reset. The firmware is now ready to | |
325 | receive loadware from the host. | |
326 | ||
327 | It is good practice to perform a command reset to the board explicitly as part | |
328 | of your software initialization. This allows your code to properly restart from | |
329 | a soft boot. (Many systems do not issue channel reset on soft boot). | |
330 | ||
331 | Because of a hardware reset problem on some of the Cirrus Logic 1400's which are | |
332 | used on the product, it is recommended that you reset the board twice, separated | |
333 | by an approximately 50 milliseconds delay. (VERY approximately: probably ok to | |
334 | be off by a factor of five. The important point is that the first command reset | |
335 | in fact generates a reset pulse on the board. This pulse is guaranteed to last | |
336 | less than 10 milliseconds. The additional delay ensures the 1400 has had the | |
337 | chance to respond sufficiently to the first reset. Why not a longer delay? Much | |
338 | more than 50 milliseconds gets to be noticable, but the board would still work. | |
339 | ||
340 | Once all 16 bytes of the Power-on Reset Message have been read, the bootstrap | |
341 | firmware is ready to receive loadware. | |
342 | ||
343 | Note on Power-on Reset Message format: | |
344 | The various fields have been designed with future expansion in view. | |
345 | Combinations of bitfields and values have been defined which define products | |
346 | which may not currently exist. This has been done to allow drivers to anticipate | |
347 | the possible introduction of products in a systematic fashion. This is not | |
348 | intended to suggest that each potential product is actually under consideration. | |
349 | ------------------------------------------------------------------------------*/ | |
350 | ||
351 | //---------------------------------------- | |
352 | // Format of Power-on Reset Message | |
353 | //---------------------------------------- | |
354 | ||
355 | typedef union _porStr // "por" stands for Power On Reset | |
356 | { | |
357 | unsigned char c[16]; // array used when considering the message as a | |
358 | // string of undifferentiated characters | |
359 | ||
360 | struct // Elements used when considering values | |
361 | { | |
362 | // The first two bytes out of the FIFO are two magic numbers. These are | |
363 | // intended to establish that there is indeed a member of the | |
364 | // IntelliPort-II(EX) family present. The remaining bytes may be | |
365 | // expected // to be valid. When reading the Power-on Reset message, | |
366 | // if the magic numbers do not match it is probably best to stop | |
367 | // reading immediately. You are certainly not reading our board (unless | |
368 | // hardware is faulty), and may in fact be reading some other piece of | |
369 | // hardware. | |
370 | ||
371 | unsigned char porMagic1; // magic number: first byte == POR_MAGIC_1 | |
372 | unsigned char porMagic2; // magic number: second byte == POR_MAGIC_2 | |
373 | ||
374 | // The Version, Revision, and Subrevision are stored as absolute numbers | |
375 | // and would normally be displayed in the format V.R.S (e.g. 1.0.2) | |
376 | ||
377 | unsigned char porVersion; // Bootstrap firmware version number | |
378 | unsigned char porRevision; // Bootstrap firmware revision number | |
379 | unsigned char porSubRev; // Bootstrap firmware sub-revision number | |
380 | ||
381 | unsigned char porID; // Product ID: Bit-mapped according to | |
382 | // conventions described below. Among other | |
383 | // things, this allows us to distinguish | |
384 | // IntelliPort-II boards from IntelliPort-IIEX | |
385 | // boards. | |
386 | ||
387 | unsigned char porBus; // IntelliPort-II: Unused | |
388 | // IntelliPort-IIEX: Bus Information: | |
389 | // Bit-mapped below | |
390 | ||
391 | unsigned char porMemory; // On-board DRAM size: in 32k blocks | |
392 | ||
393 | // porPorts1 (and porPorts2) are used to determine the ports which are | |
394 | // available to the board. For non-expandable product, a single number | |
395 | // is sufficient. For expandable product, the board may be connected | |
396 | // to as many as four boxes. Each box may be (so far) either a 16-port | |
397 | // or an 8-port size. Whenever an 8-port box is used, the remaining 8 | |
398 | // ports leave gaps between existing channels. For that reason, | |
399 | // expandable products must report a MAP of available channels. Since | |
400 | // each UART supports four ports, we represent each UART found by a | |
401 | // single bit. Using two bytes to supply the mapping information we | |
402 | // report the presense or absense of up to 16 UARTS, or 64 ports in | |
403 | // steps of 4 ports. For -IIEX products, the ports are numbered | |
404 | // starting at the box closest to the controller in the "chain". | |
405 | ||
406 | // Interpreted Differently for IntelliPort-II and -IIEX. | |
407 | // -II: Number of ports (Derived actually from product ID). See | |
408 | // Diag1&2 to indicate if uart was actually detected. | |
409 | // -IIEX: Bit-map of UARTS found, LSB (see below for MSB of this). This | |
410 | // bitmap is based on detecting the uarts themselves; | |
411 | // see porFlags for information from the box i.d's. | |
412 | unsigned char porPorts1; | |
413 | ||
414 | unsigned char porDiag1; // Results of on-board P.O.S.T, 1st byte | |
415 | unsigned char porDiag2; // Results of on-board P.O.S.T, 2nd byte | |
416 | unsigned char porSpeed; // Speed of local CPU: given as MHz x10 | |
417 | // e.g., 16.0 MHz CPU is reported as 160 | |
418 | unsigned char porFlags; // Misc information (see manifests below) | |
419 | // Bit-mapped: CPU type, UART's present | |
420 | ||
421 | unsigned char porPorts2; // -II: Undefined | |
422 | // -IIEX: Bit-map of UARTS found, MSB (see | |
423 | // above for LSB) | |
424 | ||
425 | // IntelliPort-II: undefined | |
426 | // IntelliPort-IIEX: 1 << porFifoSize gives the size, in bytes, of the | |
427 | // host interface FIFO, in each direction. When running the -IIEX in | |
428 | // 8-bit mode, fifo capacity is halved. The bootstrap firmware will | |
429 | // have already accounted for this fact in generating this number. | |
430 | unsigned char porFifoSize; | |
431 | ||
432 | // IntelliPort-II: undefined | |
433 | // IntelliPort-IIEX: The number of boxes connected. (Presently 1-4) | |
434 | unsigned char porNumBoxes; | |
435 | } e; | |
436 | } porStr, *porStrPtr; | |
437 | ||
438 | //-------------------------- | |
439 | // Values for porStr fields | |
440 | //-------------------------- | |
441 | ||
442 | //--------------------- | |
443 | // porMagic1, porMagic2 | |
444 | //---------------------- | |
445 | // | |
446 | #define POR_MAGIC_1 0x96 // The only valid value for porMagic1 | |
447 | #define POR_MAGIC_2 0x35 // The only valid value for porMagic2 | |
448 | #define POR_1_INDEX 0 // Byte position of POR_MAGIC_1 | |
449 | #define POR_2_INDEX 1 // Ditto for POR_MAGIC_2 | |
450 | ||
451 | //---------------------- | |
452 | // porID | |
453 | //---------------------- | |
454 | // | |
455 | #define POR_ID_FAMILY 0xc0 // These bits indicate the general family of | |
456 | // product. | |
457 | #define POR_ID_FII 0x00 // Family is "IntelliPort-II" | |
458 | #define POR_ID_FIIEX 0x40 // Family is "IntelliPort-IIEX" | |
459 | ||
460 | // These bits are reserved, presently zero. May be used at a later date to | |
461 | // convey other product information. | |
462 | // | |
463 | #define POR_ID_RESERVED 0x3c | |
464 | ||
465 | #define POR_ID_SIZE 0x03 // Remaining bits indicate number of ports & | |
466 | // Connector information. | |
467 | #define POR_ID_II_8 0x00 // For IntelliPort-II, indicates 8-port using | |
468 | // standard brick. | |
469 | #define POR_ID_II_8R 0x01 // For IntelliPort-II, indicates 8-port using | |
470 | // RJ11's (no CTS) | |
471 | #define POR_ID_II_6 0x02 // For IntelliPort-II, indicates 6-port using | |
472 | // RJ45's | |
473 | #define POR_ID_II_4 0x03 // For IntelliPort-II, indicates 4-port using | |
474 | // 4xRJ45 connectors | |
475 | #define POR_ID_EX 0x00 // For IntelliPort-IIEX, indicates standard | |
476 | // expandable controller (other values reserved) | |
477 | ||
478 | //---------------------- | |
479 | // porBus | |
480 | //---------------------- | |
481 | ||
482 | // IntelliPort-IIEX only: Board is installed in a 16-bit slot | |
483 | // | |
484 | #define POR_BUS_SLOT16 0x20 | |
485 | ||
486 | // IntelliPort-IIEX only: DIP switch #8 is on, selecting 16-bit host interface | |
487 | // operation. | |
488 | // | |
489 | #define POR_BUS_DIP16 0x10 | |
490 | ||
491 | // Bits 0-2 indicate type of bus: This information is stored in the bootstrap | |
492 | // loadware, different loadware being used on different products for different | |
493 | // buses. For most situations, the drivers do not need this information; but it | |
494 | // is handy in a diagnostic environment. For example, on microchannel boards, | |
495 | // you would not want to try to test several interrupts, only the one for which | |
496 | // you were configured. | |
497 | // | |
498 | #define POR_BUS_TYPE 0x07 | |
499 | ||
500 | // Unknown: this product doesn't know what bus it is running in. (e.g. if same | |
501 | // bootstrap firmware were wanted for two different buses.) | |
502 | // | |
503 | #define POR_BUS_T_UNK 0 | |
504 | ||
505 | // Note: existing firmware for ISA-8 and MC-8 currently report the POR_BUS_T_UNK | |
506 | // state, since the same bootstrap firmware is used for each. | |
507 | ||
508 | #define POR_BUS_T_MCA 1 // MCA BUS */ | |
509 | #define POR_BUS_T_EISA 2 // EISA BUS */ | |
510 | #define POR_BUS_T_ISA 3 // ISA BUS */ | |
511 | ||
512 | // Values 4-7 Reserved | |
513 | ||
514 | // Remaining bits are reserved | |
515 | ||
516 | //---------------------- | |
517 | // porDiag1 | |
518 | //---------------------- | |
519 | ||
520 | #define POR_BAD_MAPPER 0x80 // HW failure on P.O.S.T: Chip mapper failed | |
521 | ||
522 | // These two bits valid only for the IntelliPort-II | |
523 | // | |
524 | #define POR_BAD_UART1 0x01 // First 1400 bad | |
525 | #define POR_BAD_UART2 0x02 // Second 1400 bad | |
526 | ||
527 | //---------------------- | |
528 | // porDiag2 | |
529 | //---------------------- | |
530 | ||
531 | #define POR_DEBUG_PORT 0x80 // debug port was detected by the P.O.S.T | |
532 | #define POR_DIAG_OK 0x00 // Indicates passage: Failure codes not yet | |
533 | // available. | |
534 | // Other bits undefined. | |
535 | //---------------------- | |
536 | // porFlags | |
537 | //---------------------- | |
538 | ||
539 | #define POR_CPU 0x03 // These bits indicate supposed CPU type | |
540 | #define POR_CPU_8 0x01 // Board uses an 80188 (no such thing yet) | |
541 | #define POR_CPU_6 0x02 // Board uses an 80186 (all existing products) | |
542 | #define POR_CEX4 0x04 // If set, this is an ISA-CEX/4: An ISA-4 (asic) | |
543 | // which is architected like an ISA-CEX connected | |
544 | // to a (hitherto impossible) 4-port box. | |
545 | #define POR_BOXES 0xf0 // Valid for IntelliPort-IIEX only: Map of Box | |
546 | // sizes based on box I.D. | |
547 | #define POR_BOX_16 0x10 // Set indicates 16-port, clear 8-port | |
548 | ||
549 | //------------------------------------- | |
550 | // LOADWARE and DOWNLOADING CODE | |
551 | //------------------------------------- | |
552 | ||
553 | /* | |
554 | Loadware may be sent to the board in two ways: | |
555 | 1) It may be read from a (binary image) data file block by block as each block | |
556 | is sent to the board. This is only possible when the initialization is | |
557 | performed by code which can access your file system. This is most suitable | |
558 | for diagnostics and appications which use the interface library directly. | |
559 | ||
560 | 2) It may be hard-coded into your source by including a .h file (typically | |
561 | supplied by Computone), which declares a data array and initializes every | |
562 | element. This acheives the same result as if an entire loadware file had | |
563 | been read into the array. | |
564 | ||
565 | This requires more data space in your program, but access to the file system | |
566 | is not required. This method is more suited to driver code, which typically | |
567 | is running at a level too low to access the file system directly. | |
568 | ||
569 | At present, loadware can only be generated at Computone. | |
570 | ||
571 | All Loadware begins with a header area which has a particular format. This | |
572 | includes a magic number which identifies the file as being (purportedly) | |
573 | loadware, CRC (for the loader), and version information. | |
574 | */ | |
575 | ||
576 | ||
577 | //----------------------------------------------------------------------------- | |
578 | // Format of loadware block | |
579 | // | |
580 | // This is defined as a union so we can pass a pointer to one of these items | |
581 | // and (if it is the first block) pick out the version information, etc. | |
582 | // | |
583 | // Otherwise, to deal with this as a simple character array | |
584 | //------------------------------------------------------------------------------ | |
585 | ||
586 | #define LOADWARE_BLOCK_SIZE 512 // Number of bytes in each block of loadware | |
587 | ||
588 | typedef union _loadHdrStr | |
589 | { | |
590 | unsigned char c[LOADWARE_BLOCK_SIZE]; // Valid for every block | |
591 | ||
592 | struct // These fields are valid for only the first block of loadware. | |
593 | { | |
594 | unsigned char loadMagic; // Magic number: see below | |
595 | unsigned char loadBlocksMore; // How many more blocks? | |
596 | unsigned char loadCRC[2]; // Two CRC bytes: used by loader | |
597 | unsigned char loadVersion; // Version number | |
598 | unsigned char loadRevision; // Revision number | |
599 | unsigned char loadSubRevision; // Sub-revision number | |
600 | unsigned char loadSpares[9]; // Presently unused | |
601 | unsigned char loadDates[32]; // Null-terminated string which can give | |
602 | // date and time of compilation | |
603 | } e; | |
604 | } loadHdrStr, *loadHdrStrPtr; | |
605 | ||
606 | //------------------------------------ | |
607 | // Defines for downloading code: | |
608 | //------------------------------------ | |
609 | ||
610 | // The loadMagic field in the first block of the loadfile must be this, else the | |
611 | // file is not valid. | |
612 | // | |
613 | #define MAGIC_LOADFILE 0x3c | |
614 | ||
615 | // How do we know the load was successful? On completion of the load, the | |
616 | // bootstrap firmware returns a code to indicate whether it thought the download | |
617 | // was valid and intends to execute it. These are the only possible valid codes: | |
618 | // | |
619 | #define LOADWARE_OK 0xc3 // Download was ok | |
620 | #define LOADWARE_BAD 0x5a // Download was bad (CRC error) | |
621 | ||
622 | // Constants applicable to writing blocks of loadware: | |
623 | // The first block of loadware might take 600 mS to load, in extreme cases. | |
624 | // (Expandable board: worst case for sending startup messages to the LCD's). | |
625 | // The 600mS figure is not really a calculation, but a conservative | |
626 | // guess/guarantee. Usually this will be within 100 mS, like subsequent blocks. | |
627 | // | |
628 | #define MAX_DLOAD_START_TIME 1000 // 1000 mS | |
629 | #define MAX_DLOAD_READ_TIME 100 // 100 mS | |
630 | ||
631 | // Firmware should respond with status (see above) within this long of host | |
632 | // having sent the final block. | |
633 | // | |
634 | #define MAX_DLOAD_ACK_TIME 100 // 100 mS, again! | |
635 | ||
636 | //------------------------------------------------------ | |
637 | // MAXIMUM NUMBER OF PORTS PER BOARD: | |
638 | // This is fixed for now (with the expandable), but may | |
639 | // be expanding according to even newer products. | |
640 | //------------------------------------------------------ | |
641 | // | |
642 | #define ABS_MAX_BOXES 4 // Absolute most boxes per board | |
643 | #define ABS_BIGGEST_BOX 16 // Absolute the most ports per box | |
644 | #define ABS_MOST_PORTS (ABS_MAX_BOXES * ABS_BIGGEST_BOX) | |
645 | ||
cf1c63c3 JS |
646 | #define I2_OUTSW(port, addr, count) outsw((port), (addr), (((count)+1)/2)) |
647 | #define I2_OUTSB(port, addr, count) outsb((port), (addr), (((count)+1))&-2) | |
648 | #define I2_INSW(port, addr, count) insw((port), (addr), (((count)+1)/2)) | |
649 | #define I2_INSB(port, addr, count) insb((port), (addr), (((count)+1))&-2) | |
650 | ||
1da177e4 LT |
651 | #endif // I2HW_H |
652 |