Merge branch 'fix/misc' into for-linus
[linux-2.6] / drivers / char / ip2 / i2hw.h
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"
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
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
651 #endif   // I2HW_H
652