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